Monografia - Alexandre Dellai

ALEXANDRE DELLAI SCHLIEPER
APLICAO DA METODOLOGIA SIX SIGMA NA REA DE TI EM EMPRESAS DE SERVIOS
Monografia do curso de ps-graduao lato sensu MBIS - Master Business Information Systems apresentado Pontifcia Universidade Catlica de So Paulo para a obteno do ttulo de
especialista.
So Paulo 2007
ALEXANDRE DELLAI SCHLIEPER
APLICAO DA METODOLOGIA SIX SIGMA NA REA DE TI EM EMPRESAS DE SERVIOS
Monografia apresentada Pontifcia Universidade Catlica de So Paulo para a obteno do ttulo de especialista.
Orientador: Prof. Dr. Alexandre Campos Silva
So Paulo 2007
Agradecimentos
Agradeo a todos que me incentivaram a desenvolver este trabalho e me ajudaram com experincias, idias e dicas para a execuo dele. Gostaria de agradecer especialmente ao meu orientador, o Prof. Dr. Alexandre Campos, pelo seu incentivo, apoio e preciosos conselhos que viabilizaram a concluso deste trabalho bem como o corpo docente do MBIS-PUCSP.
FICHA CATALOGRFICA Schlieper, Alexandre Aplicao da Metodologia Six Sigma na rea de Ti em Empresas de Servios, 2007. 78p. Monografia programa de ps-graduao MBIS Pontifcia Universidade Catlica de So Paulo. Departamento de Computao. 1. Six Sigma. 2. Estudo de Caso. I. Pontifcia Universidade Catlica de So Paulo. Departamento de Computao.
II
Resumo
As empresas de servios investem muito em gesto de projetos, porm normalmente seu foco est na gesto da execuo dos mesmos e no se presta muita ateno no desenho da soluo que est sendo criada. Assim muitos sistemas so colocados no ar com falhas que geram um alto ndice de manuteno, um dos maiores viles na fatia do custo destas empresas. Uma alternativa para reverter esse cenrio o investimento na qualidade e o Six Sigma se apresenta no mercado como uma metodologia que tem uma abordagem com o objetivo de reduzir a taxa de falhas. Quando um processo tem seis sigma, isto representa qualidade elevada, onde a probabilidade de defeitos extremamente baixa. Projetado originalmente para ambientes de manufatura, pode ser difcil aplic-lo em processos que ainda no esto bem definidos e mensurveis. Muitas vezes as empresas de servio no sabem o quo ruins seus servios esto pela falta de mensurao. O desafio est justamente na criao destes indicadores e no estabelecimento dos nveis de acordo de servio entre as partes. Um processo pode ser aprimorado desde que mtricas como satisfao do cliente sejam estabelecidas. Levando-se em conta o custo da qualidade, a metodologia pode tambm ajudar a determinar os requisitos logo no comeo e a definir realmente as especificaes para evitar surpresas depois. Portanto o objetivo deste trabalho analisar se a metodologia Six Sigma aplicvel ou no na rea de TI em empresas de servio. As informaes apresentadas so baseadas em pesquisas bibliogrficas e um estudo de caso. Nas consideraes finais evidncias do estudo de caso sero apresentadas e analisadas.
III
Abstract
All service companies are a lot more interested in investing in project management and in doing so, the main focus, is actually on the execution of such projects rather than presenting a real solution to the failures they can bring upfront. In order to change this scenario, service companies need to make a huge investment in quality. Six Sigma is the key determinant to introduce new means to reduce failure indicators. In a Six Sigma process, with high quality control, the probability for failures in the execution process is proven to be very low. The Six Sigma is originally presented to manufacturing environment whose processes have not been either defined or measurable. Most of the times service companies do not know whether they are carrying out their services due to lack of measurement processes. The real challenge is on the upcoming of such indicators and in the establishment of parties agreements on services. Such process shall be updated once the customer satisfaction is measured. We shall take into account that quality costs are a must, so this methodology shall be at hand to attend the necessary requirements at a very early stage and thus establish goals to avoid both unnecessary and off-putting inconveniences. Therefore the objective of this paper is to analyze if the Six Sigma methodology can be applied on the IT department of a service company. All the informations presented are based upon bibliographical research and a case study. On the conclusion evidences from de case study will be presented and analyzed.
IV
Sumrio
LISTA DE FIGURAS .......................................................................................................................... 1 LISTA DE TABELAS.......................................................................................................................... 3 LISTA DE ABREVIATURAS ............................................................................................................ 4 1 INTRODUO ................................................................................................................................. 5
1.1 Objetivo.................................................................................................................. 5 1.2 Justificativa ............................................................................................................ 5 1.3 Mtodo de pesquisa................................................................................................ 6 1.4 Estrutura do trabalho .............................................................................................. 6
2 A QUESTO DA QUALIDADE EM TI......................................................................................... 8
2.1 Definio ................................................................................................................ 8 2.2 Six Sigma ............................................................................................................... 9

3 A IMPORTNCIA DA GOVERNANA CORPORA-TIVA NAS OPERAES E NO DESENVOLVIMENTO DE SISTEMAS DE TI ............................................................................. 14
3.1 COBIT.................................................................................................................. 16 3.2 Importncia do ROI.............................................................................................. 21 3.3 ITIL ...................................................................................................................... 22 3.4 CMM .................................................................................................................... 24 3.5 PMI....................................................................................................................... 26 3.6 BSC Balanced Scorecard .................................................................................. 28 3.7 ISO 27000 ............................................................................................................ 30 3.8 Conceito do Portfolio de TI ................................................................................. 31 3.9 ISO 20000 ............................................................................................................ 33
4 CONHECENDO SEIS SIGMA E O DMAIC ............................................................................... 36
4.1 Fatores Crticos de Sucesso.................................................................................. 37 4.2 Como Selecionar Projetos Six Sigma .................................................................. 38 4.3 Define (Definir).................................................................................................... 40 4.4 Measure (Medir)................................................................................................... 42
4.4.1 Diagrama de Pareto ................................................................................................................ 43 4.4.2 Lista de Verificao................................................................................................................ 44 4.4.3 Histograma ............................................................................................................................. 45 4.4.4 Diagrama de Disperso........................................................................................................... 45 4.4.5 Grfico Linear ........................................................................................................................ 46 4.4.6 Grfico (Carta) de Controle.................................................................................................... 46
4.5 Analyze (Analisar) ............................................................................................... 48

4.5.1 Fluxograma............................................................................................................................. 48 4.5.2 Mapa de Processo ................................................................................................................... 48 4.5.3 FMEA..................................................................................................................................... 49 4.5.4 Diagrama de Causa-e-Efeito................................................................................................... 50 4.5.5 Diagrama de Afinidades ......................................................................................................... 50 4.5.6 Diagrama de Relaes ............................................................................................................ 51
4.6 Improve (Melhorar).............................................................................................. 51 4.7 Control (Controlar)............................................................................................... 52 V
5 ESTUDO DE CASO: TICKET ACCOR SERVICES............................................................... 55
5.1 O Grupo Accor..................................................................................................... 55 5.2 A TI da Ticket ...................................................................................................... 56 5.3 O movimento de Governana na Ticket............................................................... 58 5.4 Define: Alto nmero de OSs............................................................................... 60 5.5 Measure: Implementao de workflow e software de classificao de OSs ...... 60 5.6 Analyse: Proposta de projetos que eliminem a causa raiz dos maiores problemas ................................................................................................................................ 63 5.7 Improve: Proposta de projetos ............................................................................. 65 5.8 Control: Controlando o efeito das solues propostas......................................... 65
6 CONSIDERAES FINAIS ......................................................................................................... 67 BIBLIOGRAFIA................................................................................................................................ 69 WEBLIOGRAFIA ............................................................................................................................. 70
VI
Lista de Figuras
Figura 1 - Mtrica do Six Sigma ................................................................................ 10 Figura 2 Comparao Um Sigma vs. Seis Sigma ................................................... 11 Figura 3 Comparao .............................................................................................. 11 Figura 4 Exemplos de performance na escala Six Sigma........................................ 12 Figura 5 Framework Governana Corporativa / Governana de TI ....................... 15 Figura 6 Focos da Governana de TI ...................................................................... 16 (fonte: IT Governance Institute) ................................................................................ 16 Figura 7 Domnios do Cobit no Framework........................................................... 17 Figura 8 Domnio Planejamento e Organizao ..................................................... 18 Figura 9 Domnio Aquisio e Implementao ...................................................... 18 Figura 10 Domnio Entrega e Suporte .................................................................... 19 Figura 11 Domnio Monitorao e Avaliao......................................................... 19 Figura 12 Cubo Cobit.............................................................................................. 19 Figura 13 Seleo de Projetos ................................................................................. 21 Figura 14 Disciplinas do ITIL ........................................................................... 22 Figura 15 Relacionamento entre Processos Suporte a Servios........................... 23 Figura 16 Relacionamento entre Processos Entrega de Servios......................... 23 Figura 17 Nveis de Maturidade.............................................................................. 25 Figura 18 Processos do PMBOK ............................................................................ 27 Figura 19 Interao entre fases do projeto .............................................................. 28 Figura 20 Tema Estratgico: Desenvolvimento de Negcios ................................. 29 Figura 21 Modelo PDCA aplicado ao ISMS .......................................................... 31 Figura 22 Derivao do Portfolio de TI.................................................................. 32 Figura 23 Processos de Gesto de Servios ISO 20000.......................................... 33 Figura 24 Core Structure ITIL V3 .......................................................................... 34 Figura 25 O segredo do sucesso do Six Sigma........................................................ 36 Figura 26 Mtodo DMAIC...................................................................................... 37 Figura 27 Matriz de seleo de projetos Six Sigma................................................. 39 Figura 28 DMAIC detalhado .................................................................................. 40 Figura 29 Exemplo de documento Project Charter................................................ 41 Figura 30 Diagrama de Pareto................................................................................. 44 Figura 31 Lista de Verificao................................................................................ 44 Figura 32 Exemplo de Histograma ......................................................................... 45 Figura 33 Exemplos de Diagramas de Disperso ................................................... 45 Figura 34 Exemplo Grfico Linear ......................................................................... 46 Figura 35 Exemplo de Grfico de Controle ............................................................ 47 Figura 36 Exemplo de Fluxograma......................................................................... 48 Figura 37 Exemplo de Mapa de Processo ............................................................... 49 Figura 38 Exemplo de FMEA ................................................................................. 49 Figura 39 Diagrama de Causa e Efeito ................................................................... 50 Figura 40 Exemplo Diagrama de Afinidades.......................................................... 51 Figura 41 Exemplo Diagrama de Relaes............................................................. 51 Figura 42 Exemplo de Matriz de Priorizao ......................................................... 52 1
Figura 43 Exemplo de Plano de Envolvimento dos Stakeholders .......................... 52 Figura 44 Correspondncia entre o mtodo DMAIC e o mtodo PDCA ............... 54 Figura 45 Marcas registradas do grupo Accor no Brasil......................................... 55 Figura 46 Servios compartilhados......................................................................... 56 Figura 47 Organograma de TI da Ticket................................................................. 57 Figura 49 Cenrio de TI: Alto nmero de OSs...................................................... 60 Figura 50 Workflow de Ordens de Servio ............................................................ 61 Figura 51 Exemplo de tela de registro de OSs com suas devidas classificaes... 62 Figura 52 Classificao, Sistemas e Mdulos impactados...................................... 63 Figura 53 Paretto das 5 principais causas de ocorrncias nos Sistemas Web......... 64 Figura 54 3 propostas de projetos ........................................................................... 65 Figura 55 Evoluo da queda de OSs aps implementao do DMAIC ............... 66
Lista de Tabelas
Tabela 1 Qualidade e defeitos sigma aplicados linguagem financeira................. 12 Tabela 2 Definio do ROI ..................................................................................... 21 Tabela 3 Exemplo de uma atividade de monitorao ............................................. 43 Tabela 4 Alguns nmeros do Grupo Accor no Brasil ............................................. 56 Tabela 5 Top 5 Paretto das OSs mais abertas .................................................... 64 Tabela 6 Prova da qualidade Six Sigma.................................................................. 66
Lista de Abreviaturas
BSC Balanced Scorecard (Kaplan; Norton, 1996) CMM (Capability Maturity Model) Cobit (Control Objectives for Information and Related Technology) DMAIC Definir (Define), Mensurar (Measure), Analisar (Analyse), Implementar (Improve), Controlar (Control) ERP Enterprise Reource Planning Framework Esquema de trabalho ISMS Sistema de Gesto da Segurana da Informao (Information Security Management System) ITIL Biblioteca de Infra-estrutura e Tecnologia da Informao (Information Technology Infrastructure Library) ITSMF (IT Service Management Forum) KPI Indicador Chave de Performance (Key Performance Indicator) OGC (Office of Government Commerce) PDCA Ciclo de qualidade total de Deming (Plan, Do, Check, Act) PMI Instituto de Gesto de Projetos (Project Management Institute) SLA Acordo de Nvel de Servio (Service Level Agreement) TI Tecnologia da Informao TPS Total Performance Scorecard TQM Gesto da Qualidade Total (Total Quality Management)
1 INTRODUO
Este estudo destinado aos profissionais e gestores da rea de TI (Tecnologia da Informao) que precisam se apoiar em metodologias para controlar a qualidade dos projetos que so entregues e a melhoria contnua dos sistemas e dos processos de produo. Com o crescimento das empresas do setor de servios, a rea de TI pode ser vista como a esteira produtiva da empresa. Muitos servios dependem de processos, sistemas e infra-estruturas de TI, logo o produto final da empresa depende fortemente de tecnologia. Este trabalho apresenta um estudo tcnico somado a uma vivncia adquirida pelo autor em aplicao da melhoria contnua na rea de TI da Ticket Accor Services atingindo reduo significativa dos custos da rea e conseqentes melhorias para os negcios.
1.1 Objetivo
O objetivo deste trabalho analisar como a metodologia de qualidade Six Sigma pode ou no ser utilizada na prestao de servios de TI, numa poca onde as empresas de servio dependem cada vez mais da tecnologia? Como se podem reduzir as falhas de implantaes de sistemas quase zero e como o processo de melhoria contnua pode reduzir custos e beneficiar os negcios contribuindo para uma melhoria de satisfao no atendimento ao cliente?
1.2 Justificativa
O Six Sigma um mtodo de aprimoramento de processo estatstico que enfoca a qualidade do ponto de vista do cliente ou do usurio. Define nveis de servio e mede variaes em relao a estes nveis. Os projetos percorrem cinco fases: definir, medir, analisar, aprimorar e controlar. Apesar dos benefcios, adotar o Six Sigma num ambiente de servios pode ser bem complexo, j que a metodologia foi desenvolvida para o ambiente de manufatura. A qualidade de um servio em particular muito subjetiva, enquanto a qualidade de um
produto manufaturado muito mais objetiva. Portanto a qualidade nas empresas de servios mais difcil de mensurar. As empresas de servio tm tanto a ganhar com o conceito quanto as indstrias. Um defeito que acontece na indstria pode ser traduzido nas empresas de servio como uma ao de um funcionrio que deixa um consumidor insatisfeito, ou a falta de imaginao na concepo de uma funcionalidade de um sistema que tenha como conseqncia a abertura de uma ordem de servio. O uso do Six Sigma uma forma mais quantitativa de medir os esforos para garantir a qualidade e efetivamente comunicar o progresso para clientes, funcionrios, fornecedores e acionistas, pois mede o desempenho em termos absolutos, e no relativos, comparando-se com a concorrncia.
1.3 Mtodo de pesquisa

Para a elaborao deste trabalho foi utilizada a metodologia de pesquisa bibliogrfica em livros, documentos publicados na Internet e um estudo de caso da empresa do segmento de benefcios Ticket Accor Services.
1.4 Estrutura do trabalho

O Six Sigma utiliza ferramentas estatsticas conhecidas h anos e o mtodo hoje se desdobra em uma tcnica conhecida como DMAIC, que busca eliminar defeitos ao longo de todos os processos da empresa. Para tanto, os captulos esto organizados da seguinte maneira: Captulo 2 A questo da qualidade em TI Captulo 3 A importncia da governana corporativa nas operaes e no desenvolvimento de sistemas e de TI Captulo 4 Conhecendo o DMAIC Captulo 5 Estudo de Caso: Ticket Accor Services Captulo 6 Consideraes Finais No captulo 2 veremos como surgiu a necessidade do controle de qualidade na rea de TI e os principais conceitos do Six Sigma. 6
No captulo 3 sero apresentadas as metodologias que suportam a Governana Corporativa e no captulo 4 ser visto o ciclo da melhoria contnua explicado pelas etapas do DMAIC: D - Define (Definir): Definir com preciso o problema-escopo do projeto; M - Measure (Medir): Determinar a localizao ou foco do problema; A - Analyze (Analisar): Determinar as causas de cada problema prioritrio; I - Improve (Melhorar): Propor, avaliar e implementar solues para cada problema prioritrio; C - Control (Controlar): Garantir que o alcance da meta seja mantido no longo prazo. J no captulo 5 ser apresentado o estudo de caso da Ticket com base na experincia do autor e vivncia da aplicao dos conceitos do Six Sigma e da aplicao das melhores prticas das metodologias que compe a Governana Corporativa que foram definidos nos captulos 3 e 4. Finalmente sero apresentadas as consideraes finais no captulo 6.
2 A QUESTO DA QUALIDADE EM TI
2.1 Definio
No quesito qualidade no se pode pensar apenas nos aspectos relacionados ao desenvolvimento de software, mas tambm nos demais aspectos que esto debaixo do guarda chuva de TI, como: Suporte Tcnico Segurana da Informao Produo CPD (Centro Processamento de Dados) Envolvimento de Terceiros Quando se fala em Suporte Tcnico existe uma preocupao muito grande com treinamento dos analistas de suporte. O mesmo pode ser realizado de forma presencial ou por telefone e para tanto muitas situaes (documentao) e scripts (passo-a-passo) devem ser elaborados. Um dos processos que mais geram demanda para o suporte tcnico so problemas com senha, logo, sempre necessrio existir um procedimento de positivao (validao positiva, confirmao) do usurio que est solicitando o suporte. O item Service Desk da metodologia ITIL (a ser apresentada adiante) trata destes assuntos. Outro ponto importante a elaborao das polticas de segurana da informao. Por exemplo, se necessrio liberar um acesso de um usurio a um sistema, o mesmo dever ser realizado por tempo determinado, e com anlise de perfil (somente consulta, novos registros e manuteno de registros). A Produo CPD se responsabiliza pela manuteno e integridade de todos os sistemas que esto no ar, normalmente uma gerncia que se reporta Infraestrutura ou o CIO diretamente e est constantemente monitorando toda a atividade da empresa, alm de ter uma clara noo da sazonalidade e dos dias do ms de maior atividade nos sistemas por rea da empresa. Atualmente no mercado fala-se muito em terceirizao (outsourcing), significa que parte dos funcionrios da empresa vem de fora. Normalmente acontece com a maioria das atividades que no esto diretamente ligadas ao core-business (atividade principal) da empresa. Este movimento comeou com a rea de contas a receber sob
responsabilidade da rea Financeira e se estende hoje para TI com infra-estrutura (hospedagem, link) e desenvolvimento de software. Quando se fala de Tecnologia da Informao em relao probabilidade de defeitos, deve-se ter em mente que os defeitos no so somente de software. Podem ser: Indisponibilidade de acesso, queda de servidores, abnormal end (parada abrupta, mais conhecido como abend) de produo, invaso de hackers, defeitos nos fornecimentos de produtos e servios de terceiros envolvidos na operao, acidentes com equipamentos, defeitos em estaes, quedas de links, perda da integridade de produtos de software, podem ser considerados defeitos da mesma forma. H tambm aspectos a serem analisados em relao aos defeitos por obsolescncia do parque instalado (hardware) e tambm da obsolescncia dos sistemas em uso na organizao. Logo importante prestar muita ateno aos contratos. Hoje em dia cada vez mais comum a venda de hardware e software no modelo de servios, logo ao invs de adquirir um equipamento ou um sistema, empresas do tipo ASP (Application Service Providers), ou Provedores de Servios de Aplicao, se preocupam com esses detalhes e garantem a disponibilidade de um sistema especfico na verso mais atualizada e com performance. muito importante mensurar esta garantia atravs de SLAs (Service Level Agreements, ou Acordo de Nvel de Servio). Por exemplo, quando adquirimos uma licena de um software de ERP (Enterprise Resource Planning, ou Sistemas Integrados de Gesto Empresarial), deve constar no contrato a previso de lanamento no mercado da prxima verso ou release e, caso a empresa no deseje comprar a nova verso, por quanto tempo a verso adquirida ter suporte disponvel.
2.2 Six Sigma

O Six Sigma uma metodologia estruturada que foi desenvolvida pela Motorola na dcada de 80 e implementada com sucesso para a melhoria de processos, apoiada em dois pilares principais: Ferramentas Estatsticas Mtodo de Soluo de Problemas
O termo foi cunhado pelo engenheiro da Motorola, Bill Smith, em 1986. Este conceito foi desenvolvido a partir de informaes vindas da fora de vendas, a respeito da grande quantidade de reclamaes de uso de garantias pelos clientes. No incio da dcada de 90 surgiram as primeiras consultorias e o conceito foi adotado por companhias como Sony, Polaroid, Kodak e GE. (Shiba et al., 1993) O nvel de qualidade Sigma ou escala Sigma de qualidade o nmero de desvios padro do processo, existentes entre a mdia do processo (m) e o limite de especificao. Na figura 1 pode-se ver uma relao entre a capacidade de um processo e o nmero de defeitos por milho.
Figura 1 - Mtrica do Six Sigma

(fonte: Werkema, 2004)
Na figura 2 se pode perceber a diferena de uma qualidade Um Sigma para uma qualidade Seis Sigma. Nota-se no primeiro quadro que existe 31,74% de perda e no segundo quadro 0,00000002 % de perda. Fazendo uma analogia para um sistema complexo como um ERP que pode possuir 1.000.000 linhas de cdigo, se o processo produtivo fosse um sigma, teramos 317.400 linhas com erros de cdigo e no caso de um processo seis sigma, teramos apenas 0,002 linhas, ou seja, nenhuma.
10
Figura 2 Comparao Um Sigma vs. Seis Sigma

importante levar em conta tambm que fica muito dispendioso ter e manter um processo Seis Sigma, logo a aplicabilidade do nvel sigma deve ser verificada de acordo com o contexto, conforme ilustra a figura 3. Para um processo de pouso e decolagem de um aeroporto muito importante ter um processo Seis Sigma, pois as falhas poderiam causar grandes desastres pondo em risco a vida do homem. J no caso do processo de logstica das bagagens, seria muito caro manter este processo dentro de uma qualidade Seis Sigma e esse custo certamente se refletiria no preo da passagem. (Werkema, 2004)
Figura 3 Comparao
Quanto maior o nvel de qualidade sigma, melhor. Tudo o que fazemos um processo ou faz parte de um, que por sua vez possui caractersticas que podem ser medidas. Os resultados das medies seguem uma freqncia de distribuio (variao) e, por fim, os clientes tm expectativas em relao performance de nosso 11
processo. Na figura 4 pode-se ver uma curva mostrando o nvel do processo e suas aplicaes mais comuns, bem como seu ndice de defeitos.
Figura 4 Exemplos de performance na escala Six Sigma

Outra viso que est apresentada na Tabela 1 o custo da no qualidade, ou seja, quanto representa em percentual do faturamento da empresa o nvel de qualidade no qual seu processo est consolidado.
Nvel da qualidade Dois sigma Trs sigma Quatro sigma Cinco sigma Seis sigma
Defeitos por milho (ppm) 308.537 66.807 6.210 233 3,4
Percentual conforme 69,15 93,32 99,3790 99,97670 99,999660
Custo da no qualidade (% do faturamento da empresa) No se aplica 25 a 40% 15 a 25% 5 a 15% < 1%
Tabela 1 Qualidade e defeitos sigma aplicados linguagem financeira No Brasil, as primeiras empresas comearam a adotar Six Sigma em 1996. Atualmente o Six Sigma fortemente utilizado na Motorola, GE, Multibrs, Belgo Mineira, Nokia, Votorantim, Ambev, Ford, Dow, Lder Txi Areo, ALL, Carbocloro, Motorola, 3M, Johnson Controls, Visteon, Alcan, Sony, Cummins, Du Pont, Johnson & Johnson, etc. No Japo a indstria atingiu 10 defeitos por parte de milho e o Brasil encontra-se atualmente em 10000 defeitos por parte de milho. (Pande, Neuman e Cavanagh, 2001)
12
Os conceitos do Six Sigma serviram de base para a criao de outras metodologias que surgiram no mercado. No prximo captulo pode-se perceber a existncia desses conceitos nas metodologias que suportam a Governana Corporativa e a aplicabilidade dessa metodologia, que surgiu na indstria, nas empresas de servio.
13
3 A IMPORTNCIA DA GOVERNANA CORPORATIVA NAS OPERAES E NO DESENVOLVIMENTO DE SISTEMAS DE TI

O alinhamento estratgico o ponto de partida para a Governana de TI, considerando criao de valor para o negcio e aderncia a requisitos de conformidade (tambm conhecidos no mercado como requisitos de compliance). De forma geral, as organizaes vivenciam problemas para realizar o alinhamento da tecnologia da informao com a estratgia de negcios, portanto pode-se considerar a implantao de um modelo de Governana para abordar questes como: Falta de alinhamento entre o objetivo da rea de TI e os objetivos corporativos da organizao Falta de controle de qualidade de servios Repetio desnecessria de trabalhos Desperdcio de sinergias Dificuldades na incorporao de conhecimentos / inovaes Dificuldades na gesto de recursos humanos Despesas e investimentos crescentes Funes dispersas A partir dos objetivos e estratgias de negcio so desenhadas as estratgias de TI, que so transformadas em projetos e servios. Alm das estratgias de negcio, atualmente muitas organizaes se preocupam com o atendimento a instrumentos de regulamentao internos e externos. Aps o alinhamento estratgico com os objetivos de negcio, as prioridades de TI precisam ser definidas. As prioridades podem ser projetos de aplicativos, manutenes ou processos definindo assim o portfolio de TI. definido o que ser mantido e em que deve ser investido e um mecanismo de deciso corporativa um Comit de Projetos com a participao dos usurios e executivos. Na figura 5 um framework (estrutura de trabalho) representa como a Governana Corporativa trabalha juntamente com a Governana de TI. No passo 1, utiliza-se o 14
Cobit para controlar se os planos de TI esto aderentes Governana Corporativa, que tem como misso garantir que a estratgia de empresa esteja sendo seguida e no passo 2, utilizam-se diversas metodologias para cumprir o plano de TI (Governana de
TI).
(Fernandes e Abreu, 2006)
Figura 5 Framework Governana Corporativa / Governana de TI

(fonte: DMR Consulting)
A empresa que opta pelas boas prticas de governana corporativa adota como linhas mestras transparncia, prestao de contas (accountability) e eqidade. Para que essa trade esteja presente em suas diretrizes de governo, necessrio que o Conselho de Administrao, representante dos proprietrios do capital (acionistas ou cotistas), exera seu papel na organizao, que consiste especialmente em estabelecer estratgias para a empresa, eleger a Diretoria, fiscalizar e avaliar o desempenho da gesto e escolher a auditoria independente. (IBCG, 2005)
15
3.1 COBIT
O Cobit (Control Objectives for Information and Related Technology) foi criado em 1994 com o objetivo de controle, e vem evoluindo atravs da incorporao de padres internacionais tcnicos, profissionais, regulatrios e especficos para processos de TI. Em 2005 o Cobit j evoluiu para a verso 4.0 atravs de prticas e padres mais maduros em conformidade com as regulamentaes da governana de TI e na sua abrangncia para gestores, tcnicos, especialistas e auditores de TI. O objetivo do modelo contribuir para o sucesso da entrega de produtos e servios de TI, a partir das necessidades do negcio, com um foco mais acentuado no controle ao invs da execuo. O modelo genrico bastante para representar todos os processos normalmente encontrados em TI, e compreensvel tanto para gerentes de negcio como para a operao, proporcionando uma ponte entre o que o pessoal operacional vai executar e a viso que os executivos desejam ter para gerenciar. (ISACA, 2005) Os pilares funcionais que sustentam o ncleo de Governana de TI podem ser representados em cinco reas conforme a figura 6:
Figura 6 Focos da Governana de TI (fonte: IT Governance Institute) Alinhamento Estratgico: Garantir a ligao entre negcio e os planos de TI, alinhando as operaes da empresa com as de TI. Agregao de Valor: Agregar valor com os benefcios das entregas de TI de acordo com a estratgia, otimizando custos.
16
Gerenciamento de Recursos: Otimizar investimentos nas operaes crticas de TI (aplicaes, informaes, infra-estrutura e pessoas) essencialmente para atender os requisitos de negcio. Gerenciamento de Riscos: Divulgar os riscos para a alta direo, compreender os requisitos de compliance (conformidade) e incorporao de responsabilidades para gerenciar os riscos. Medio de Desempenho: Acompanhar e monitorar a implementao da estratgia, do andamento dos projetos, da utilizao dos recursos, do desempenho dos processos e da entrega dos servios utilizando indicadores de desempenho (como o Balanced Scorecard que ser visto em detalhes mais adiante) que traduzem a estratgia em aes para atingir objetivos mensurveis. O Cobit fortemente orientado por processos, permitindo assim que todos em uma organizao sejam capazes de identificar e gerenciar atividades em TI. Assim como no ciclo de melhoria contnua que nasceu no Six Sigma (planejar, construir, executar e monitorar), o Cobit identificou 34 processos que foram devidamente agrupados e distribudos em quatro domnios, identificados na figura 7.
ME PO
DS AI
Figura 7 Domnios do Cobit no Framework

(fonte: adaptado do IT Governance Institute)
17
(PO) Planejamento e Organizao: Este domnio tem abrangncia estratgica e ttica e identifica as formas que TI pode contribuir para melhorar o atendimento dos objetivos de negcio. (AI) Aquisio e Implementao: Este domnio responsvel pela identificao de desenvolvimento ou aquisio de solues de TI para executar a estratgia de TI estabelecida. (DS) Entrega e Suporte: Vem do ingls, Delivery e Support. Este domnio cobre a entrega dos servios requeridos, incluindo gerenciamento da segurana, servios aos usurios, gesto de dados e da infra-estrutura operacional. (ME) Monitorao e Avaliao: Este domnio assegura a qualidade dos processos de TI, assim como a sua conformidade com os objetivos de controle atravs de monitorao e avaliaes externas e internas. Dentro de cada domnio existem processos que levam a metas de negcio. Essas metas so definidas de forma que haja correlao entre elas e quais metas de TI iro suport-las. As metas por atividade permitem o acompanhamento eficaz do desempenho do processo. Os processos que compe cada domnio so vistos nas figuras 8, 9, 10 e 11.
Figura 8 Domnio Planejamento e Organizao
Figura 9 Domnio Aquisio e Implementao
18
Figura 10 Domnio Entrega e Suporte
Figura 11 Domnio Monitorao e Avaliao Portanto o Cobit pode ser definido pela viso integrada atravs do Cubo ilustrado na figura 12.
Figura 12 Cubo Cobit

(fonte: adaptado do IT Governance Institute)
Os Recursos de TI (IT Resources) so gerenciados por Processos de TI (IT Processes), para atingir metas de TI, que por sua vez esto ligadas aos requisitos de negcio. Em cada objetivo de controle que auxilia o negcio, a informao deve ser provida dentro de certos critrios (Information Criteria) conforme tabela 2. 19
Effectiveness Informao deve ser relevante e pertinente aos processos de negcios bem como ser entregue com temporalidade, corretude, consistncia, e usabilidade. Efficiency Informao deve ser provida com o uso de recursos da forma mais produtiva e econmica.
Confidentiality Informao sensvel deve ser protegida de acesso no autorizado.
Integrity Informao deve ser precisa e completa, bem como sua validade deve estar em concordncia com o conjunto de valores e expectativas do negcio.
Availability Informao deve ser disponvel quando requerida pelo processo de negcio agora e no futuro, e deste modo deve ser salvaguardada enquanto recurso. Compliance Informao deve estar em conformidade com leis, regulamentos, e arranjos contratuais dos quais os processos de negcios esto sujeitos. Reliability of Information Informao deve ser provida de forma
apropriada, permitindo seu uso na operao da organizao, na publicao de relatrios financeiros para seus usurios e rgos fiscalizadores, conforme leis e regulamentos. Tabela 2 Qualidade de Critrios de Informao
20
3.2 Importncia do ROI

Outro aspecto importante a anlise de retorno sobre o investimento (ROI) para criao do conhecimento nas organizaes de TI bem como da estrutura necessria. Quando a organizao decide investir em TI, a mesma est visando o aumento da produtividade, o fornecimento de melhores informaes para o gerenciamento, a reduo de custos, o conseqente aumento da receita / lucro e finalmente satisfao do cliente. Para tanto necessrio justificar estes investimentos e demonstrar seus resultados atravs de uma anlise de ROI. Com essa prtica cria-se uma base slida para tomada de deciso, pode-se avaliar uma oportunidade de desenvolvimento, medir as respostas do mercado e facilitar o planejamento. O ROI pode ser qualitativo ou quantitativo. Na tabela 3 se encontram suas respectivas caractersticas: Quantitativo
VPL valor presente lquido TIR taxa interna de retorno Payback Business case Reduo de custos
Qualitativo
Melhoria de performance Automao de atividades Controles financeiros Simplificao de processos Renovao de servidores
Tabela 3 Definio do ROI Com uma anlise de ROI podem-se mostrar os riscos e custos de oportunidade construindo-se cenrios e analisando alternativas de projetos conforme exemplo da figura 13. Alto
Alto
Figura 13 Seleo de Projetos 21
Conforme visto o Cobit a metodologia utilizada para reportar o andamento da Governana de TI para os executivos da empresa que so responsveis pelas estratgias de negcio definido na Governana Corporativa (passo 1 do framework). J quando o foco a Governana de TI, existem diversas metodologias que ajudam a controlar todos os aspectos envolvendo a rea de TI (passo 2 do framework). A seguir sero apresentados os conceitos de cada uma dessas metodologias que compe a Governana de TI.
3.3 ITIL
O ITIL (Information Technology Infrastructure Library) foi desenvolvido pelo CCTA (Central Computer and Telecommunications Agency) no final dos anos 80, a partir de uma encomenda do governo britnico, que no estava satisfeito com os servios prestados por TI. Nessa oportunidade foi desenvolvido um conjunto de melhores prticas para utilizar e gerenciar os recursos de TI. (OCG, 2001) O ITIL um modelo composto por um conjunto de publicaes relacionadas aos domnios considerados importantes no contexto do gerenciamento de servios de TI. Estes domnios so inter-relacionados em uma estrutura tipo quebra-cabea mostrada conforme figura 14.
Figura 14 Disciplinas do ITIL Os processos do ITIL esto agrupados em dois principais domnios, que compe sua espinha dorsal, so eles:
22
Suporte a Servios (Service Support): Processos com foco operacional, que visam assegurar o acesso dos usurios aos servios apropriados que suportam as funes do negcio, conforme figura 15.
Figura 15 Relacionamento entre Processos Suporte a Servios

(fonte: adaptado de OGC)
Entrega de Servios (Service Delivery): Processos de nvel ttico que o negcio requer do provedor, para que seja assegurada a entrega do servio aos clientes de forma adequada, conforme figura 16.
Figura 16 Relacionamento entre Processos Entrega de Servios

(fonte: adaptado de OGC)
Todos os processos do ITIL possuem uma forte relao de interdependncia e atuam conjuntamente no tratamento de diversos eventos possveis no ciclo de vida de um servio de TI. 23
Concluindo, o ITIL muito forte em processos de TI, mas limitado em segurana e desenvolvimento de sistemas, j o Cobit forte em controles de TI e mtricas de TI, mas no diz como o fluxo dos processos e fraco em segurana. Portanto para se ter uma viso completa em Governana de TI necessrio utilizar todo o leque de metodologias que compe o guarda-chuva do Cobit, conforme os itens seguintes que sero abordados.
3.4 CMM
O CMM (Capability Maturity Model for Software), ou Modelo de Maturidade da Capacitao para software um modelo de qualidade de estrutura que descreve os principais elementos de um processo de software efetivo. Como as empresas necessitam de diversas aplicaes de software para diferentes atividades, de diferentes fornecedores, cada um com sua gesto e modelos prprios de desenvolvimento, arquitetura e abordagem de implementao. Diante deste cenrio em 2002 foi criado um modelo evolutivo em relao aos vrios nveis de CMMs numa estrutura nica, componentizada e evolutiva pelo SEI - Software Engineering Institute (Instituto de Engenharia de Software), sediado na CMU - Carnegie Mellon University, em Pittsburgh, PA, Estados Unidos. (CMU, 2001) O modelo implica capacitao da organizao, a mesma precisa estar habilitada para sistematicamente produzir software possuindo a qualidade esperada, dentro dos prazos concordados e com os recursos alocados. Quanto maior a capacitao, menor ser a variao dos erros de estimativa em torno da mdia. Ao melhorar o processo, ou seja, fortalecendo as propriedades de ser definido, praticado, gerenciado, medido e controlado (maturidade do processo), possvel melhorar os produtos. Assim, reduz-se a faixa de incerteza quanto aos resultados esperados (capacitao do processo). O modelo enfatiza a documentao dos processos, seguindo a premissa de que, para realizar alguma melhoria no processo, preciso primeiro conhec-lo e entend-lo, e que a qualidade de um produto reflexo da qualidade e gerenciamento do processo utilizado em seu desenvolvimento. No existem solues prontas. Qualquer que seja
24
o processo de desenvolvimento utilizado, ele precisa ser adaptado empresa e aos projetos por ela desenvolvidos. O CMM prope um caminho gradual que leva as organizaes a se aprimorarem continuamente na busca da sua prpria soluo dos problemas inerentes ao desenvolvimento sistemtico de software, portanto possui nveis de maturidade que estabelecem um conjunto coerente de metas que melhoram a capacitao da organizao e fazem com que desenvolvam software de forma mais organizada, cada vez com menos problemas de qualidade e menos erros de estimativa de prazo e de necessidade de recursos. Cada nvel de maturidade (com exceo do nvel 1) possui reas-chave de processo (key process area) que o constituem e, para cada rea-chave, existem prticas-chave (key practices) que devem ser implementadas de modo que se possa atingir as metas dessa rea-chave. As prticas-chave no estabelecem como devem ser realizadas, pelo contrrio, o CMM visa aproveitar os mtodos e as ferramentas j existentes na organizao. As prticas-chave apenas determinam as caractersticas que devem ser satisfeitas.
Figura 17 Nveis de Maturidade Os componentes do modelo CMM tambm podem ser agrupados em categorias que refletem o modo como devem ser interpretados: Requeridos: Absolutamente necessrios para implementao de uma rea de processo. Ex: Metas. 25
Esperados: Compe uma implementao tpica de uma rea de processos, porm aceitando alternativas que produzem resultados satisfatrios. Ex: Prticas. Informativos: Auxiliam no entendimento das metas e prticas, e das formas como podem ser implementadas. Ex: Notas, Referncias. As reas de processo se dividem em Gesto do Processo, Gesto do Projeto, Engenharia e Suporte. O CMM pode ser implementado em qualquer empresa cujo foco seja o desenvolvimento de produtos do tipo software e sistemas. De acordo com um relatrio publicado pelo SEI em 2003 o modelo traz benefcios quantificveis como redues de custo, de esforo do re-trabalho, do nmero de defeitos para mais ou menos 5 em cada 1000 linhas de cdigo. No existe o conceito de certificao individual ou empresarial, a qualificao de organizaes no nvel de maturidade feita atravs de avaliaes formais a partir de critrios de alto nvel definidos pelo SEI, no qual empresas avaliadoras autorizadas pelo SEI montam uma equipe de avalistas especialistas que iro liderar o processo de avaliao nas empresas. A validade da avaliao oficial de no mximo 3 anos, portanto a cada 3 anos as organizaes devero ser novamente submetidas a uma avaliao oficial de mesmo nvel ou superior, para que suas credenciais junto ao SEI sejam mantidas.
3.5 PMI
O Project Management Institute uma organizao no governamental dedicada s necessidades dos gerentes de projeto de todo o mundo. Atravs da publicao PMBOK (Project Management Base of Knowledge) que j est na sua terceira verso, o PMI divulga as boas prticas da gesto de projeto e a aplicao correta de habilidades, ferramentas e tcnicas para aumentar as chances de sucesso de qualquer tipo de projeto. O modelo est estruturado em nove reas de conhecimento: Gerenciamento da Integrao do Projeto; Gerenciamento do Escopo do Projeto;
26
Gerenciamento do Prazo do Projeto; Gerenciamento do Custo do Projeto; Gerenciamento da Qualidade do Projeto; Gerenciamento dos Recursos Humanos do Projeto; Gerenciamento da Comunicao do Projeto; Gerenciamento dos Riscos do Projeto; Gerenciamento das Aquisies do Projeto. J os processos de gerenciamento de projetos, representados pelas nove reas do conhecimento so agrupados, de acordo com o modelo representado na figura 18:
Figura 18 Processos do PMBOK Grupo de processos de iniciao: define e autoriza o projeto Grupo de processos de planejamento: define e refina os objetivos e planeja as aes necessrias para alcanar os objetivos e escopo para os quais o projeto foi idealizado. Grupo de processos de execuo: que integra pessoas e outros recursos para realizar o plano de gerenciamento do projeto. Grupo de processos de monitoramento e controle: mede e monitora o progresso para identificar variaes em relao ao plano de gerenciamento do projeto, visando a tomada de aes corretivas.
27
Grupo de processos de encerramento: formaliza a aceitao do produto, servio ou resultado e conduz o projeto ou uma fase do projeto a um final ordenado. Pode-se ver na figura 19 o nvel de atividade desses processos ao longo do tempo e como eles interagem entre si.
Figura 19 Interao entre fases do projeto O PMBOK pode ser aplicado em gerenciamento de projetos de qualquer natureza, inclusive projetos de tecnologia da informao. A nfase do modelo sobre a gesto de projetos e no sobre a engenharia de desenvolvimento do produto resultante do projeto. Este modelo pode ser adaptado e utilizado de forma consistente em uma organizao de TI. Deve ser estabelecido um processo de gerenciamento de projetos que aplique as boas prticas de acordo com o contexto da empresa, formando-se assim uma metodologia prpria de gesto de projetos.
3.6 BSC Balanced Scorecard

A partir do ano 2000 as reas de TI adotaram fortemente os conceitos do Balanced Scorecard, que surgiram na dcada de 90, como ndice de mtodos estatsticos, para mensurar defeitos no desenvolvimento, suporte, segurana e produo. O BSC, como chamado, surgiu atravs de uma pesquisa do Nolan Norton Institute, sobre a medio de desempenho de uma organizao. Segundo Kaplan e Norton (2000), a medio de desempenho de uma empresa somente considerando indicadores financeiros estava obsoleta, e basear-se somente nessas medidas inabilitava as empresas a criar valores econmicos futuros. 28
Representantes de diversas empresas com sistemas inovadores de medio de desempenho participaram do estudo da Nolan Norton, liderado por Kaplan e em 1990 um novo modelo de medio de desempenho foi proposto. Os participantes do grupo de estudo focaram sua ateno para um scorecard (tabela de pontos) multidimensional. A proposta resultou no que chamaram de Balanced Scorecard BSC, organizado por quatro perspectivas: financeira, clientes, processos internos e aprendizado e crescimento, determinando assim uma relao de causa-e-efeito, assim como relaciona objetivos com medies, metas e iniciativas, que so os projetos e servios que devem ser implantados para o atendimento aos objetivos e metas. Este nome foi dado com o objetivo de refletir um balano entre objetivos de curto e longo prazo, medidas financeiras e no financeiras, indicadores de resultados e desempenho. Com o uso e aperfeioamento o BSC, passou de uma sistemtica de medio de indicadores de desempenho para um sistema de gesto estratgica de uma empresa, e que tambm pode ser aplicado como um sistema de controle e comunicao da estratgia. Logo os executivos podem relacionar as vises da estratgia da empresa s perspectivas do BSC, formando assim um Mapa Estratgico da empresa, representado na figura 20.
Figura 20 Mapa Estratgico: Desenvolvimento de Negcios
29
Um Mapa Estratgico bem estruturado uma ferramenta poderosa para a efetiva gesto estratgica da organizao rumo a sua viso de futuro. Alm disso, o Mapa Estratgico um instrumento de comunicao e alinhamento das equipes em um foco comum. As iniciativas ou projetos a serem implantados podem estar refletidos no Portfolio de TI. Em TI, o BSC pode ser usado durante o planejamento da tecnologia da informao, assim como na gesto do dia-a-dia da realizao da estratgia de TI. Verifica-se no BSC uma relao de causa e efeito que colabora para a elaborao de um planejamento eficaz e da gesto de desempenho por toda a organizao.
3.7 ISO 27000

Algumas normas de Segurana da Informao tiveram sua origem no Governo Britnico. Tudo comeou com a British Standard (BS) 7799 que nasceu em 1989 e foi criada para certificar fornecedores de produtos de segurana em TI e criar um cdigo de boas prticas para os usurios de TI. As normas foram evoluindo e em 2005 a BS 7799 transformou-se na ISO/IEC 27001. A ISO (International Organization for Standarization) e o IEC (International Eletrotechnical Comission) esto lanando a srie 27000. A srie foi preparada para estabelecer, implantar, operar, monitorar, rever, manter e melhorar um Sistema de Gesto de Segurana da Informao (ISMS), do ingls, Information Security Management System. Esta norma adota o princpio de gesto por processos enfatizando a importncia de: Entender os requisitos de segurana da informao e a necessidade de se implantar uma poltica. Implementar controles para gerenciar os riscos. Monitorar e rever o desempenho e a eficcia do ISMS. Promover a melhoria contnua. A norma tambm adota o ciclo PDCA (Plan-Do-Check-Act) que aplicado na estrutura de todos os seus processos. Na figura 21 se pode ver como um ISMS se comporta em relao ao modelo PDCA. 30
Figura 21 Modelo PDCA aplicado ao ISMS

(fonte: adaptado de ISO 2005e)
A utilizao de um modelo como esse em empresas de servio de TI bem recomendvel, por proporcionar maior garantia de proteo dos ativos de informao. Os benefcios da segurana da informao esto na preveno de perdas financeiras que as empresas podem ter, no caso de riscos relacionados segurana da informao.
3.8 Conceito do Portfolio de TI

Outro ponto importante originado na Governana de TI est relacionado criao do Portfolio de Projetos e Ordens de Servio. O alinhamento estratgico o ponto de partida. A partir dos objetivos e estratgias do negcio, derivam-se as iniciativas de TI, que so transformadas em projetos e servios e, assim, forma-se o plano estratgico de TI. Deve-se lembrar que atualmente muitas organizaes fazem frente ao atendimento a instrumentos de regulao internos e externos, como o SarbanesOxley Act e o Acordo da Basilia II. A Sarbanes-Oxley uma lei que visa proteger investidores do mercado de fraudes contbeis e financeiras de companhias de capital aberto, assim como instituir uma srie de penalidades contra crimes relacionados. J o Acordo Basilia II atinge instituies financeiras em geral, estabelecida pelo BIS (Bank for International Settlements) que estipula requisitos de capital mnimos, em funo dos seus riscos de crdito e operacionais.
31
Ambas regulamentaes tm forte impacto na rea de TI e fazem parte do modelo de Governana de TI. Seu atendimento est nos requisitos de diversos projetos que fazem parte do portfolio de TI e que vo criar restries s operaes de servios de TI. Fazem parte do portfolio de TI, solues estratgicas, projetos de aplicativos ou solues, projetos de manuteno de ativos ou projetos de processos, organizao e servios. A definio sobre o que manter e sobre em que investir vai depender dos mecanismos de deciso corporativos, como por exemplo, um Comit de Projetos com a participao de usurios e executivos das demais reas da empresa. O portfolio de TI deve direcionar o relacionamento com os clientes (internos e externos), assim como com os fornecedores e parceiros de TI. Demandas que no estiverem enquadradas no portfolio no devem ser atendidas, pois o mesmo est constantemente alinhado com os objetivos e estratgias do negcio. Na figura 22 podem ser observados os domnios de conhecimento do portfolio de TI, segundo o PMI.
Portfolio TI Total de investimentos em TI (agrupados em classes de ativos), incluindo tecnologias, servios, outsourcing e Pessoas. Viso de um fluxo de servios
Programas TI
Agrupamento de projetos alinhados com os objetivos de Negcios.
Projetos TI
Conjunto de atividades alinhadas ao oramento e cronograma.
Atividades de TI Capacidades bsicas (especificaes, codificao, testes, integrao,
Figura 22 Derivao do Portfolio de TI

(fonte: PMI)
32
3.9 ISO 20000

As normas internacionais ISO (Organizao Internacional de Normalizao, ou International Organization for Standards) relacionadas com a Gesto de Servios de TI permitem a colaborao de organizaes internacionais e fornecem diretrizes valiosas que contribuem para o estabelecimento da credibilidade das empresas. Uma nova norma, a ISO 20000, disponvel no final de 2006, permite a uma organizao demonstrar aos seus clientes e investidores que opera com integridade e segurana, e que promove uma cultura de melhoramento contnuo da qualidade no mbito da Gesto de Servios de TI. (BMC Software White Paper, 2006) Esta nova norma fomenta a adoo de uma abordagem de processos integrada para um fornecimento eficaz de servios de TI e define as diretrizes de qualidade para a gesto de servios de TI (ITSM IT Service Management) conforme figura abaixo.
Figura 23 Processos de Gesto de Servios ISO 20000

(fonte: BMC Software White Paper, 2006)
O estabelecimento da ISO 20000 demonstra que a TI chegou a um ponto de maturidade em que poucas organizaes podero sobreviver sem ela. A documentao que define esta norma foi publicada em 2005 e a certificao global comeou a ser aplicada no incio de 2006. Esta nova norma baseia-se na norma britnica BS 15000 e est estreitamente alinhada com a IT Infrastructure Library (ITIL). ISO 20000 um cdigo que fornece um critrio de medio e validao do
33
sucesso de uma organizao na implementao das melhores prticas, conforme definidas pelo ITIL. As organizaes que obtiveram ou procuram obter a certificao BS 15000 e as organizaes que esto a implementar a ITIL estaro j no caminho certo para a obteno da ISO 20000, tendo conseqentemente a capacidade de aumentar a sua credibilidade como organizaes. importante que as organizaes avaliem o potencial impacto da norma, e a determinar se devem procurar obter a certificao. Qualquer que seja o caso, as organizaes que planejam implementar a ITIL para melhorar a qualidade da sua prestao de servios de TI podero utilizar a ISO 20000 como modelo de referncia para seu progresso j que a ISO uma norma. No caso do ITIL foi lanada no mercado a verso 3.0 em Junho de 2007 que trata do portfolio de servios, onde a estratgia de servios est no centro do ciclo de vida do ITIL. Neste novo modelo, a estratgia comea com os resultados desejados do consumidor e todo provedor de servios est sujeito a foras competitivas conforme figura 24. (itSMF, 2007)
Figura 24 Core Structure ITIL V3

(fonte: itSMF, 2007)
34
Como a verso 3 traz um foco na estratgia de servios, com a preocupao no design do servio que est separada em cinco aspectos: Design da soluo de servios. Design das ferramentas de gesto de servios (e outros sistemas de suporte). Design da arquitetura da tecnologia e sistemas de gesto. Design dos processos. Design dos sistemas de mensurao, mtricas e mtodos. O que mais importante compreender acerca da ISO 20000 e da ITIL que ambas necessitam de um melhoramento contnuo, fator este que permitir aumentar a credibilidade e competitividade de uma empresa.
Todos os conceitos ora apresentados so utilizados no dia-a-dia da empresa Ticket Accor Services. No captulo 5, quando ser abordado o estudo de caso, exemplos sero mostrados de como estes conceitos de governana, gesto e qualidade contriburam para o trabalho realizado.
35
4 CONHECENDO SEIS SIGMA E O DMAIC

Segundo Deming (1993) a Gesto da Qualidade Total (TQM) tem foco na gesto e melhoria contnua dos processos e uma filosofia e um conjunto de diretrizes baseado no ciclo de aprendizado de Deming, mais conhecido como ciclo PDCA (Planejar, Desenvolver, Controlar e Agir corretivamente). So usadas ferramentas estatsticas conhecidas h anos na busca da eliminao de defeitos em todos os processos da empresa. No entanto, apesar de as ferramentas no serem novidades, sua abordagem e a forma de implementao so nicas e muito poderosas, o que explica o sucesso do programa que pode ser definido como uma estratgia empresarial para aumentar a lucratividade. Veja figura 25.
Figura 25 O segredo do sucesso do Six Sigma

Um dos principais elementos da infra-estrutura do Six Sigma a constituio de equipes para executar projetos que contribuam fortemente para o alcance das metas estratgicas da empresa. O desenvolvimento desses projetos realizado com base em um mtodo denominado DMAIC. O mtodo do DMAIC do Six Sigma tambm pode ser aplicado na mensurao e melhoria na capacidade de remover defeitos de software. Estes defeitos podem ser detectados na fase de teste de software. Um bom sistema de consolidao de ordens de servio pode ter um indicador que mostre a quantidade de defeitos por cdigo produzido. Antes de detalhar a aplicao do mtodo, o Six Sigma precisa se preocupar em selecionar projetos relevantes (que ser visto em detalhes mais adiante). Projetos
36
bem selecionados levaro a resultados rpidos e significativos e, conseqentemente contribuiro para o sucesso e a consolidao da cultura Six Sigma na empresa. Segundo Deming (1993) o mtodo DMAIC definido por cinco etapas: D - Define (Definir): Definir com preciso o problema-escopo do projeto; M - Measure (Medir): Determinar a localizao ou foco do problema; A - Analyze (Analisar): Determinar as causas de cada problema prioritrio; I - Improve (Melhorar): Propor, avaliar e implementar solues para cada problema prioritrio; C - Control (Controlar): Garantir que o alcance da meta seja mantido no longo prazo.
Figura 26 Mtodo DMAIC

4.1 Fatores Crticos de Sucesso

Os programas de melhoria so de extrema relevncia, porm devem estar integrados, pois, caso contrrio, a implantao e a manuteno isolada dissipam recursos humanos e financeiros, causam competio desnecessria entre setores da empresa e acarretam o descrdito dos colaboradores. Neste contexto, diversos pesquisadores
37
tm estudado o impacto destes programas nos resultados das organizaes, bem como os fatores crticos de sucesso na implementao destes programas. Banuelas e Antony (2003) pesquisaram os fatores-chave para a efetiva adoo dos programas Seis Sigma, bem como entender as ferramentas e tcnicas que suportavam este programa. Os autores fizeram um levantamento em empresas de grande porte (mais de 1000 empregados) do Reino Unido, que priorizaram como fator de maior importncia o envolvimento e comprometimento da alta administrao. Outros fatores que receberam grau de importncia acima da mdia foram as habilidades de gerenciamento de projeto, a priorizao e seleo de projeto, as revises da documentao e foco no cliente. Entre os fatores com prioridade abaixo da mdia esto o alinhamento estratgia de negcio, treinamento e entendimento da metodologia Seis Sigma, ferramentas e tcnicas estatsticas. Nilsson et al. (2001) realizaram um levantamento em 360 empresas de manufatura e 122 empresas de servios com mais de 50 funcionrios na Sucia. O objetivo da pesquisa era de examinar o impacto da gesto de pessoas, orientao a processos e orientao ao consumidor na satisfao do consumidor. Os autores verificaram que a orientao a processos tem um maior impacto positivo na satisfao do consumidor para empresas de servio do que para empresas de manufatura. Alm disto, a orientao ao consumidor tem um maior impacto positivo na satisfao do consumidor para empresas de manufatura do que para empresas de servio. No que concerne gesto de pessoas, observou-se um maior impacto positivo nos resultados para empresas de servios do que para empresas de manufatura.
4.2 Como Selecionar Projetos Six Sigma

A seleo de projetos uma fase fundamental da metodologia Six Sigma. Segundo Deming (1993), primeiramente o projeto deve ter forte contribuio para o alcance das metas estratgicas da empresa e aumento da satisfao dos clientes, alm de uma elevada chance de concluso dentro do prazo estabelecido. O projeto tambm deve gerar grande impacto para a melhoria da performance da organizao, considerando qualidade e ganhos financeiros. Por meio do emprego de
38
mtricas apropriadas, a quantificao dos resultados que devem ser alcanados no projeto deve ser precisa. Um dos fatores mais determinantes tambm o patrocnio por parte da alta administrao da empresa e dos demais gestores envolvidos. O principal objetivo da seleo de projetos gerar uma matriz contendo aspectos relevantes como: Prazo dos projetos: Podem ser de mdio prazo (quatro a seis meses) ou longo prazo (oito a doze meses). Complexidade dos projetos: Se o projeto se apresentar muito amplo o escopo dever ser alterado. importante estabelecer metas ambiciosas, porm as mesmas devem sempre ser atingveis. Ganhos resultantes dos projetos: Demonstrar prazo do retorno financeiro e/ou melhoria da performance da rea que ser diretamente afetada pelo projeto. Pode-se ver um exemplo da matriz para seleo de projetos na figura 27.
Figura 27 Matriz de seleo de projetos Six Sigma

39
A seguir sero descritas as etapas do DMAIC em detalhes e tambm algumas ferramentas empregadas nas etapas do mtodo. O mtodo sistemtico e baseado em dados e no uso de ferramentas estatsticas para se atingirem os resultados estratgicos buscados pela empresa. Na figura 28 pode-se ver de forma resumida todos os objetivos e atividades de cada uma das etapas do ciclo.
Figura 28 DMAIC detalhado

4.3 Define (Definir)

Na primeira etapa do DMAIC, a meta e o escopo do projeto devero ser claramente definidos. As seguintes perguntas devero ser respondidas: Qual o problema a ser abordado no projeto? Resultado indesejvel ou oportunidade detectada. Qual a meta a ser atingida?
40
Quais so os clientes afetados pelo problema? Qual o impacto econmico do projeto? O principal produto desta etapa o documento Project Charter (figura 29) que representa uma espcie de contrato firmado entre a equipe responsvel pela conduo do projeto e os gestores da rea envolvida.
Figura 29 Exemplo de documento Project Charter

41
Pelo exemplo mostrado na figura 29 existe uma Descrio do problema que demonstra indicadores e mtricas utilizadas para medir o problema, os resultados esperados, o impacto da soluo do problema e as conseqncias caso o problema no seja resolvido. A rea responsvel pela elaborao do Project Charter a rea solicitante, portanto uma descrio de problema bem feita muito importante, pois garante que a equipe responsvel pelo desenvolvimento da soluo entendeu corretamente a situao apresentada. A Definio da meta constituda por um objetivo gerencial (problema ou oportunidade), um valor e um prazo. A Avaliao do histrico do problema representa todos os fatos e dados histricos que ajudam no entendimento e valorizao do problema. Por exemplo, podem ser apresentadas perdas de faturamento por produtos no entregues no prazo, gastos com horas extras de funcionrios para recuperao da produo e etc. Essas trs primeiras informaes so necessrias para uma primeira avaliao do problema onde a rea solicitadora e a rea solucionadora se reuniro para definir, em equipe, e avaliar se o projeto realmente prioritrio para a unidade de negcio e se ser encaminhado para comit de aprovao. O item Restries e Suposies dever apresentar restries como baixo tempo de dedicao dos membros da equipe solucionadora, ou inexistncia de dados confiveis. Tambm devem ser documentadas suposies associadas a necessidade de suporte de especialistas ou consultores internos. O documento tambm deve apresentar a identificao e as responsabilidades dos membros da equipe e um cronograma macro preliminar do projeto.
4.4 Measure (Medir)

Nesta etapa o problema ser refinado, logo devem ser medidos dados teis que tenham foco no problema. Dependendo do problema, o mesmo dever ser dividido em outros problemas de menor escopo, de mais fcil soluo. Os dados representam o ponto de partida para esta etapa. A equipe dever decidir se os dados j existentes so suficientes ou se novos dados devero ser coletados. Freqentemente os dados j
42
existentes no so confiveis. Neste momento a forma de estratificao dos novos dados dever ser bem discutida, portanto deve-se ter certeza do tempo dos dados (dia, ms atual, ms passado, semestre), local (regies, cidades, filiais, segmentos de mercado), tipo (depende do fornecedor, do produto, do consumidor), sintoma (devoluo, recusa, parada de produo, falta de material), individuo (operador, turma, vendedor, supervisor). Uma importante ferramenta desta atividade o Plano de Coleta de Dados que pode ser entendido como 5W1H Who, What, Where, When, Why e How. O Que
Detectar falhas nos processadores dos servidores UNIX
Quem
Operador
Por qu
Para manter a disponibilidade do ambiente
Quando
24h/dia
Onde
Na sala de operao, no console do sistema de gerenciamento
Como
Cada servidor UNIX possui um cone que o representa. A falha de um processador indicada com o cone em vermelho. Nessa situao deve ser chamado o fornecedor do equipamento imediatamente
Tabela 4 Exemplo de uma atividade de monitorao Muitas vezes nessa etapa precisamos de um sistema de coleta de dados. importante verificar o processo e a adoo de um sistema que consiga estratificar os dados conforme a necessidade para verificao do problema/oportunidade definidos. Toda coleta de dados realizada precisa de sadas de dados. Essas sadas podem ser realizadas de diversas formas que auxiliaro a etapa seguinte que a anlise da situao.
4.4.1 Diagrama de Pareto

O diagrama de Pareto um recurso grfico utilizado para estabelecer uma ordenao nas possveis causas de problemas que devem ser sanados. O diagrama torna visivelmente clara a relao ao/benefcio, ou seja, prioriza a ao que trar o melhor resultado.
43
Figura 30 Diagrama de Pareto

Analisando um diagrama da figura 30, fica claro que tipo de defeito melhor atacar, pois o mesmo estabelece prioridades mostrando em que ordem os problemas precisam ser resolvidos.
4.4.2 Lista de Verificao

Permite uma coleta de dados organizada, facilitando sua anlise e interpretao.
Figura 31 Lista de Verificao

Existe uma infinidade de tipos de lista de verificao. O mais importante que haja facilidade no seu preenchimento e que os dados sejam apontados de modo correto. A forma de coleta de dados depende do objetivo do estudo. Na figura 31, pode-se ver a variao de um nmero de determinadas ocorrncias conforme a variao de uma voltagem.
44
4.4.3 Histograma
uma forma de descrio grfica de dados quantitativos, agrupados em classes de freqncia. Na figura 32 pode-se ver um determinado nmero de ocorrncias agrupadas numa determinada freqncia.
Figura 32 Exemplo de Histograma

4.4.4 Diagrama de Disperso

Pode ser utilizado para identificar se existe uma tendncia de variao conjunta (correlao) entre duas ou mais variveis.
Figura 33 Exemplos de Diagramas de Disperso

importante perceber que neste tipo diagrama deve-se analisar variveis que tm correlao. No exemplo da figura 33 percebe-se que na anlise do Peso vs. Altura
45
existe correlao, e j na anlise QI vs. Tamanho do Sapato no existe quase nenhuma correlao.
4.4.5 Grfico Linear

Permite que seja avaliada a evoluo de um conjunto de dados ao longo do tempo, caso os dados sejam contnuos (srie temporal).
Figura 34 Exemplo Grfico Linear

4.4.6 Grfico (Carta) de Controle

Permite avaliar se o comportamento de um processo, em termos de variao, (ou no) previsvel. Neste grfico o eixo horizontal representa o tempo e, o vertical, o valor da caracterstica (pontos), que por sua vez ficam unidos por segmentos de reta. No grfico ainda devem ser plotadas trs linhas horizontais: limite inferior de controle, limite superior controle e linha mdia.
46
Figura 35 Exemplo de Grfico de Controle

Durante a etapa Measure, tambm muito importante investigar o prprio local da ocorrncia do problema. Muitas vezes nem todas as coletas podem ser obtidas em forma de dados numricos, portanto necessria a adio de evidncias como faturas, embalagens, etiquetas, envelopes, ou seja, qualquer produto que pode servir de evidncia para o problema definido.
47
4.5 Analyze (Analisar)

Na terceira etapa do DMAIC, devero ser determinadas as causas fundamentais do problema prioritrio associado a cada uma das metas definidas na etapa anterior. A parte mais importante desta etapa responder pergunta: por que o problema prioritrio existe? Nesta fase as causas fundamentais do problema precisam ser descobertas e para isso necessrio realizar dois tipos de anlise. O primeiro consiste no exame do processo gerador do problema prioritrio, chamado de (Process Door), para permitir um melhor entendimento do fluxo e a identificao de oportunidades para reduo do tempo de ciclo e dos custos do processo. Ferramentas como Fluxograma, Mapa de Processo e FMEA so extremamente teis conduo dessa anlise.
4.5.1 Fluxograma
O Fluxograma usado para a visualizao das etapas e caractersticas de um processo. So analisadas tambm caractersticas como fluxos de deciso, gerao de re-trabalho, refluxo e complexidade.
Figura 36 Exemplo de Fluxograma

4.5.2 Mapa de Processo

O Mapa de Processo utilizado para documentar o conhecimento existente sobre o processo. Descreve os limites, as principais atividades/tarefas, os parmetros de produto final e do processo.
48
Figura 37 Exemplo de Mapa de Processo

4.5.3 FMEA
O FMEA uma ferramenta que tem como objetivo identificar, hierarquizar e prevenir as falhas potenciais de um produto ou processo. utilizado para identificao das variveis crticas que podem afetar a qualidade, assim como avaliao dos riscos e auxlio para descoberta das causas fundamentais de um problema.
Figura 38 Exemplo de FMEA

O prximo passo consiste na anlise de dados do problema prioritrio e de seu processo gerador (Data Door). Nessa fase so examinados dados provenientes da etapa Measure, com o objetivo de descobrir indicaes sobre as possveis causas potencias do problema prioritrio. A equipe deve organizar uma lista de causas potenciais, para maior facilidade de visualizao por meio de uso de ferramentas como Diagrama de Causa e Efeito, Diagrama de Afinidade e Diagrama de Relaes.
49
4.5.4 Diagrama de Causa-e-Efeito

O diagrama de Causa e Efeito tambm conhecido como espinha de peixe ou Ishikawa, que foi um dos pioneiros nas atividades de qualidade no Japo. Este diagrama constitui uma tcnica visual que interliga os resultados (efeitos) com os fatores (causas).
Figura 39 Diagrama de Causa e Efeito

Este diagrama permite estruturar hierarquicamente as causas de determinado problema ou oportunidade de melhoria, bem como seus efeitos sobre a qualidade. Permite tambm estruturar qualquer sistema que necessite de resposta de forma grfica e sinttica.
4.5.5 Diagrama de Afinidades

O Diagrama de Afinidades a representao grfica de grupos de dados que tm entre si alguma relao que os distinguem dos demais.
50
Figura 40 Exemplo Diagrama de Afinidades

4.5.6 Diagrama de Relaes

O Diagrama de Relaes permite a visualizao das relaes de causa e efeito de um problema, a partir de um conjunto de dados no numricos. Sua utilizao recomendada quando as relaes entre as causas de um problema so complexas e necessrio evidenciar que cada evento no resultado de uma causa nica, porm de vrias causas relacionadas.
Figura 41 Exemplo Diagrama de Relaes

A fase do Analyse corresponde quantificao da importncia das causas potenciais prioritrias do problema considerado. importante destacar que as ferramentas utilizadas nesta fase podem variar e dependem muito do problema abordado pelo projeto. Portanto as causas fundamentais estaro identificadas e quantificadas, de modo a constiturem a base para a gerao de solues que ocorrero na prxima etapa do DMAIC.
4.6 Improve (Melhorar)

Na quarta etapa do DMAIC, inicialmente devem ser geradas idias sobre solues potenciais para a eliminao das causas fundamentais do problema prioritrio detectadas na etapa Analyse. A etapa comea com um brainstorming e as idias levantadas nesta fase devem ser refinadas e combinadas para darem origem s solues potenciais para o alcance da
51
meta. O uso de ferramentas como Diagrama de Causa e Efeito, Diagrama de Afinidades ou Diagrama de Relaes poder auxiliar a equipe na conduo dessa tarefa. muito importante que as solues potenciais sejam elaboradas de modo claro e formalmente registradas. O prximo passo consiste na priorizao das solues potenciais atravs de um Diagrama de Matriz (figura 42) ou de uma Matriz de Priorizao (figura 43). Outra ferramenta importante o Stakeholder Analysis, onde no caso o stakeholder pode ser uma pessoa e rea e esse quadro mostrar o grau de comprometimento de cada stakeholder com a soluo.
Figura 42 Exemplo de Matriz de Priorizao

Figura 43 Exemplo de Plano de Envolvimento dos Stakeholders

Aps os devidos testes da soluo, possveis ajustes e implementao, a equipe deve avaliar se a soluo selecionada teve potencial suficiente para levar ao alcance da meta.
4.7 Control (Controlar)

Nesta ltima etapa os resultados obtidos aps a implementao das solues devem ser monitorados para a confirmao do alcance do sucesso (problema eliminado ou oportunidade atingida conforme a meta). Se o resultado for favorvel, a prxima fase
52
consistir na padronizao das alteraes realizadas no processo em consequncia das solues adotadas. Deve-se pensar em incorporar atividades prova de erro assim como monitores e processos que enfatizem na deteco e correo de erros. A prxima fase da etapa Control consiste em definir e implementar um plano para monitoramento da performance e do alcance da meta. Essa fase muito importante para impedir que o problema j resolvido ocorra novamente no futuro.
Por fim vale lembrar que o ciclo DMAIC representa uma evoluo do ciclo PDCA, ou ciclo de Deming, introduzido no Japo aps a guerra. O ciclo comea pelo planejamento, em seguida as aoes so executadas, checa-se o que foi feito, se estava de acordo com o planejado, constantemente e ciclicamente e toma-se uma ao para eliminar ou ao menos mitigar defeitos no produto ou na execuo. Os passos so os seguintes: Plan (planejamento): estabelecer misso, viso, objetivos (metas), procedimentos e processos (metodologias) necessrias para o atingir os resultados. Do (execuo): realizar, executar as atividades. Check (verificao): monitorar e avaliar periodicamente os resultados e processos, confrontando-os com o planejado, objetivos, especificaes e estado desejado consolidando as informaes. Act (agir): Agir de acordo com o avaliado e de acordo com os relatrios, eventualmente determinar e confeccionar novos planos de ao, de forma a melhorar a qualidade, eficincia e eficcia, aprimorando a execuo e corrigindo eventuais falhas.
53
D C
Improve
Analyze
De fin e
Figura 44 Correspondncia entre o mtodo DMAIC e o mtodo PDCA

l ro nt Co
M easure
54
5 ESTUDO DE CASO: TICKET ACCOR SERVICES

Entre as reas funcionais de TI, a rea de suporte a sistemas pode ser muito complexa para administrar, tanto pela complexidade inerente aos aplicativos, como tambm pela alta demanda por servios de outras reas usurias. Esta rea est sempre sobrecarregada com correes de falhas sistmicas, novas necessidades de informao, dvidas dos usurios e pequenas melhorias que ocorrem no agitado diaa-dia de TI. So esforos dedicados em investimentos de novos projetos e manutenes dos aplicativos em operao.
5.1 O Grupo Accor

A Accor um grupo mundial de Hotelaria, Turismo e Servios que, em 30 anos de Brasil, criou 30.000 empregos diretos e no qual 60.000 empresas-cliente e 5 milhes de usurios depositam sua confiana. Atualmente possui 2,5 milhes de cartes eletrnicos ativos e foi eleita, pelos seus colaboradores, por 9 vezes, como uma das Melhores Empresas para se Trabalhar, segundo pesquisa realizada pela Revista Exame. Na figura 45 pode-se ver as marcas e segmentos que a Accor atua no Brasil.
Figura 45 Marcas registradas do grupo Accor no Brasil

(fonte: Ticket Accor Services, 2005)
Todos os nmeros do grupo Accor esto representados na tabela 4.
55
Volume de negcios em 2005

Marcas de Produtos e Servios Empresas-clientes Consumidores/dia Estabelecimentos credenciados Cartes eletrnicos emitidos Unidades hoteleiras Apartamentos Restaurantes administrados de Empresas Refeies servidas por dia Postos de Viagem Passagens emitidas por ano
R$ 8,0 bilhes
28 60.000 5.000.000 280.000 2,5 milhes 126 18.789 850 680.000 150 930.000
Tabela 4 Alguns nmeros do Grupo Accor no Brasil
5.2 A TI da Ticket
A misso da rea de TI Prover e gerir servios de Tecnologia da Informao alinhados com as Estratgias dos Negcios e interesses dos Acionistas, garantindo a competitividade. No contexto da Accor e de servios compartilhados a Ticket se encontra na figura 46 da seguinte maneira.
Figura 46 Servios compartilhados

A rea de TI possui 70 colaboradores divididos no seguinte organograma representado na figura 47:
56
Figura 47 Organograma de TI da Ticket

E os profissionais que trabalham na rea cuidam das seguintes tecnologias e seus aplicativos representados na figura 48:
Figura 48 Principais tecnologias

A seguir ser analisado um estudo de caso da Ticket com base na metodologia do DMAIC.
57
5.3 O movimento de Governana na Ticket

No incio de 2005 os executivos da empresa Ticket do Grupo Accor decidiram investir no redesenho do Modelo de Governana. Com a complexidade da tecnologia somada crescente dependncia de Tecnologia pelo Negcio era necessria uma maior integrao entre os Sistemas e Solues de negcio da Ticket. A rea de Negcios possui necessidades cada vez mais distintas e a presso por reduo de custos, flexibilidade e agilidade era cada vez maior. Logo era necessrio criar um modelo de gesto organizacional que atendesse s exigncias dos acionistas, pois o perfil da concorrncia estava mudando e o mercado passou a ser cada vez mais agressivo em relao a novas tecnologias. Com o crescimento das ameaas e vulnerabilidades e a constante dificuldade para arbitrar Custo x Qualidade x Risco o modelo de Gesto de TI era insuficiente. Todos esses motivos causaram uma reflexo do grupo de executivos representados por diversas reas da empresa e diversas questes foram discutidas assim como: Se havia uma viso clara da funo de TI e de como ela pode contribuir para o negcio? O retorno sobre o investimento em TI real? mensurvel? As decises certas estavam sendo tomadas? TI est custando tanto quanto deveria? Sabe-se fornecer e operar sistemas com excelncia operacional? Sabe-se extrair o mximo dos sistemas ao longo do tempo? Corre-se risco de exposio? Confia-se na liderana e nos recursos de TI? Todos esses questionamentos levaram a concluses de que todos os indicadores de negcio construdos pelo BSC teriam de ser atualizados e utilizados para tornar TI 100% transparente e manter objetivos comuns com a rea de Negcios alinhados com a estratgia corporativa. A equipe passou a compreender conceitos de Negcios e TI, os bons profissionais foram mantidos e a responsabilidade da gesto de projetos foi dividida com a rea de Negcios. Logo os projetos de TI tiveram seu foco 58
alterado para projetos de Negcios e os profissionais foram capacitados em gesto de projetos com base na metodologia PMI. Para promover a melhor integrao possvel entre as reas de Negcio e TI, cargos chamados de CPN (Coordenadores de Processos e Negcios) firam criados, onde este coordenador ficou subordinado diretoria das reas de negcios, porm o mesmo tambm era avaliado pela diretoria de tecnologia. A responsabilidade do CPN era concentrar e priorizar as demandas das reas de negcio enquanto CPS (Coordenador de Processos e Sistemas) subordinado diretoria de tecnologia tem como responsabilidade fazer a ponte com as reas de Negcios, atravs do CPN, e TI. Alm disso, foram criadas duas coordenaes novas na rea de Tecnologia. A primeira respondendo diretamente para a diretoria executiva de TI, chamada Coordenao de Projetos e Qualidade de TI que tem o papel de PMO (Project Management Office, ou Escritrio de Projetos) e o QA (Quality Assurance, ou Auditor da Qualidade). Esta coordenao concentrava e divulgava todos os indicadores de performance e projetos da rea de TI, para a diretoria executiva que j estava prxima s demais diretorias executivas das reas de negcio. A outra coordenao criada foi a Coordenao de Processos Corporativos, respondendo diretamente para a diretoria adjunta de TI, responsvel pelo mapeamento e manuteno de todos os processos corporativos da empresa, bem como a sua ligao com a arquitetura de TI. Logo quando um projeto novo ou melhoria eram propostos, a primeira atividade a ser realizada era a verificao de quais processos corporativos estavam relacionados com esta proposta e conseqentemente qual eram os sistemas e mdulos envolvidos. As melhores prticas de todas as metodologias vistas no captulo 3 foram adotadas e adaptadas para o contexto da Ticket. As coordenaes de Planejamento/Qualidade e Processos Corporativos, mais as coordenaes especficas por cada rea de sistemas juntaram esforos para garantir a aplicao de uma metodologia de gesto de projetos e desenvolvimento de sistemas por todos os seus colaboradores com o objetivo de buscar a excelncia operacional e a aderncia Governana Corporativa da empresa e seu planejamento estratgico.
59
5.4 Define: Alto nmero de OSs

A Ticket identificou em 2005 que deveria utilizar um mtodo para avaliar quais demandas so mais prioritrias do que outras, atendendo assim de forma satisfatria a todos. Nesta poca foi quando a rea de sistemas, alinhada ao Programa de Governana de TI, decidiu implantar mecanismos de gesto destas demandas por meio de ordens de servio (OSs). Em Julho de 2005 a rea de TI da Ticket obteve o nmero de 796 ordens de servio abertas por ms conforme figura 49.
Figura 49 Cenrio de TI: Alto nmero de OSs

5.5 Measure: Implementao de workflow e software de classificao de OSs

Com o apoio de usurios-chave e das reas de processos, escritrio de projetos, infraestrutura, o departamento definiu uma nova organizao para segregar os times responsveis para atuar em projetos e para manter o ambiente em operao, alm de criar regras que definissem quando o atendimento deveria ser mesmo considerado uma ordem de servio. Ou seja, foi criado um apoio aos usurios tanto em manuteno como no suporte. Uma regra importante definida de imediato foi a limitao em 40 horas para o atendimento de cada demanda. Acima deste limite, a demanda deveria ser considerada como um projeto. Um conjunto de ordens de servio que supera tal 60
limite, agrupadas por tema e aplicativo, gera um pr-projeto que submetido s reas usurias para deliberao e aprovao do investimento (ROI). Para organizar o processo, negociou-se com cada uma das reas usurias a identificao de um coordenador, que responde pelo acompanhamento e o grau de importncia de tais demandas, alm de negociar com outras reas a soluo dos conflitos de atendimento. Com as regras definidas, os processos mapeados, as responsabilidades delegadas e a nova estrutura organizacional implementada, faltava a tecnologia que suportaria os fluxos. Afinal, TI necessita de aplicativos que controlem as demandas e facilitem a anlise de tendncias. S assim podem-se identificar oportunidades que melhorem a qualidade no uso dos aplicativos e que reduzam os custos fixos da rea. O desafio era transferir horas aplicadas em suporte e manuteno para a prtica da inovao. Depois de trs meses de estudos, foi implantado um software para o controle das demandas para garantir a agilidade dos processos desde sua abertura at a concluso do atendimento. Assim, toda a cadeia sistmica do software passou a ser apoiada por um workflow (figura 50) e, desde ento, a equipe de sistemas recebe a demanda do prprio usurio solicitante com a sua identificao, os aplicativos envolvidos (ERP Enterprise Resource Planning, CRM Customer Relationship Management, Legado, Web, BI Business Intelligence), mdulo, classificao e a prioridade.
Figura 50 Workflow de Ordens de Servio

61
Outro ponto muito importante foi a centralizao das ordens de servio no software, assim como procedimento da rea fechamos todas as outras maneiras possveis de uma demanda chegar em TI, como email, telefone, reunio, etc. A orientao geral passada para todas as reas da empresa era de que devia-se abrir uma ocorrncia utilizando o software, onde a mesma seria devidamente catalogada em Sistema, Mdulo, tipo de problema, o que facilita o agrupamento e conseqente identificao de causa raiz dos problemas. Outra premissa importante foi que o software (figura 51) deveria ser web-based, ou seja, construdo em plataforma web, para que pudesse ser acessado de qualquer filial da empresa sem onerar a infra-estrutura com procedimento de instalao.
Figura 51 Exemplo de tela de registro de OSs com suas devidas classificaes

62
5.6 Analyse: Proposta de projetos que eliminem a causa raiz dos maiores problemas
Aps a implementao do software de controle de demandas (visto no captulo 4) todas as coordenaes da rea de sistemas foram desafiadas a descobrir as causasraiz dos problemas e propor solues. As diferentes reas de Sistemas e Projetos da Ticket so divididas em: Sistemas Operaes Sistemas Financeiros Sistemas Extrator Sistemas e Projetos TC (Ticker Combustvel) / TSeg (Ticket Seguro) Sistemas e Projetos TT (Ticket Transporte) Sistemas e Projetos BI Sistema e Projetos WEB Na poca o autor deste trabalho era responsvel pelos Sistemas Web da empresa, portanto os dados que sero mostrados a seguir so especficos da anlise desta rea.
Figura 52 Classificao, Sistemas e Mdulos impactados

63
Com base nas classificaes do software de abertura de OSs (figura 52), as ocorrncias foram agrupadas usando o princpio da classificao ABC num diagrama de Paretto identificando assim as causas dos problemas conforme tabela 5.
TOP 05
Excluso de empresa e-Ticket Excluso de Interlocutor Descentralizar Unidade Migrar funcionrios Incluir contrato na carga
JULHO 2005 Posio Qtd

1 2 3 4 5 64 43 20 18 8
%
41,83 28,10 13,07 11,76 5,23
Tabela 5 Top 5 Paretto das OSs mais abertas

180 160 N de Ocorrncias 140 120 100 80 60 40 20 0 Excluso de empresa eTicket Excluso de Interlocutor Descentralizar Unidade Causas Migrar funcionrios Incluir contrato na carga
Figura 53 Paretto das 5 principais causas de ocorrncias nos Sistemas Web

Na rea de Sistemas Web esta ao foi carinhosamente apelidada de Top 5, ou seja no fechamento de todos os meses todas as ocorrncias so analisadas e so identificadas as cinco ocorrncias que mais acontecem. Projetos so propostos para eliminar as ocorrncias com maior nmero de incidncias, para assim reduzir de forma eficaz as ocorrncias na rea de TI.
64
5.7 Improve: Proposta de projetos

Com todas as informaes organizadas que as ferramentas das etapas anteriores trouxeram, foi mais fcil elaborar propostas de projetos ou melhorias para atacar as principais causas-raiz dos problemas encontrados. De acordo com a Governana de TI, todos os projetos devem passar pelo comit deliberativo e as reas de negcio devem traz-los e defend-los. Neste caso foram elaboradas propostas de melhorias para trs projetos: Excluso de Empresa e-Ticket, Excluso de Interlocutor, Descentralizar Unidade. Os trs representam,
respectivamente, 64, 43 e 20 ordens de servio, que somadas representam 127 OSs de um total de 251 SOs da rea de WEB, so mais de 50%.
180 160 N de Ocorrncias 140 120 100 80 60 40 20 0 Excluso de empresa eTicket Excluso de Interlocutor Descentralizar Unidade Causas Migrar funcionrios Incluir contrato na carga
Figura 54 3 propostas de projetos

Como no rateio final dos custos da empresa, as reas de negcio acabam pagando a conta de TI, portanto os projetos foram aprovados e deliberados no comit, pois todos tinham o seu ROI Retorno sobre Investimento comprovado em menos de seis meses e acabariam reduzindo os custos de TI e conseqentemente aumentando a rentabilidade do negcio da empresa.
5.8 Control: Controlando o efeito das solues propostas

Nesta ltima etapa do DMAIC utilizando-se o mesmo software da etapa Measure, mede-se novamente todas as ocorrncias e pode-se verificar que a causa raiz foi corretamente atacada, pois as ocorrncias caram para zero. Essa a maior evidncia de que o projeto tem qualidade Six Sigma.
65
Esse o principal objetivo da etapa Control, verificar que os projetos foram bem sucedidos atingindo assim o seu objetivo de atingir a causa-raiz do problema, conforme tabela 6. TOP 05
Excluso de empresa e-Ticket Excluso de Interlocutor Descentralizar Unidade Migrar funcionrios Incluir contrato na carga Alterao de Razo Social no Cadastro Pedidos Descarga de Pedidos
JULHO 2005 Pos Qtd

1 2 3 4 5 64 43 20 18 8
SET 2005 Pos Qtd

0 0 0 28 7 6 10
1 3 4 2
Tabela 6 Prova da qualidade Six Sigma

Acima um quadro comparativo das ocorrncias em Julho de 2005, quando foi tomada a iniciativa dos projetos, versus o ms de Setembro de 2005 onde evidenciamos a no ocorrncia das causas e como o DMAIC um ciclo de melhoria contnua observa-se um novo Top 5 onde novas propostas de projetos sero discutidas e apresentadas. Esse o principal objetivo do mtodo DMAIC, a melhoria contnua. Abaixo se observa a evoluo das quedas de ocorrncias na rea de Sistemas Web.
231
102
Figura 55 Evoluo da queda de OSs aps implementao do DMAIC

66
6 CONSIDERAES FINAIS
O funcionamento de uma rea de tecnologia de uma organizao pode utilizar diferentes bibliotecas, metodologias e frameworks tais como COBIT, ITIL e CMM e apoiar-se tambm na obteno de certificaes tanto para profissionais como para empresas. A metodologia de qualidade Seis Sigma foi analisada e apesar da sua aplicao estar originalmente voltada para o processo produtivo, verifica-se que a metodologia tambm pode ser aplicada na rea de prestao de servios de tecnologia da informao. No estudo de caso, foram analisados os resultados obtidos na rea de suporte de servios de TI. Os resultados do caso foram satisfatrios e mostram que o Seis Sigma pode ser utilizado na melhoria da prestao de servios de TI, melhorando o atendimento aos clientes. O estudo de caso mostra que a aplicao do mtodo Seis Sigma de melhoria contnua DMAIC, possvel identificar oportunidades de melhorias de relatrios para eliminar a necessidade de abrir uma ordem de servio pelos usurios, reforo no treinamento no uso dos aplicativos, desenvolvimento de mdulos acessrios para apoiar a operao rotineira de certos departamentos, ajustes no dimensionamento da equipe de sistemas, amadurecimento dos usurios e a melhor delas, a satisfao no atendimento. Tambm foi possvel mensurar a mdia horria para o atendimento de demandas, o custo unitrio e o mapa de alocao de cada hora trabalhada. A rea de sistemas deixou de ser vista como uma caixa preta, pois est atuando de maneira transparente e assertiva. E o melhor: as reas ficaram mais prximas e assumiram responsabilidades distintas na administrao das prioridades. Foi, inclusive, eliminada uma barreira entre sistemas e usurios, j que eles passaram a ter mais critrio no uso dos servios de TI, pelo fato de visualizarem os custos envolvidos. Os nmeros so ainda mais otimistas. Em 2006, o volume de ordens de servio foi reduzido em 32% e o backlog em 30%. A empresa est satisfeita com os resultados alcanados e a equipe est compreendendo que, alm de um bom trabalho tcnico,
67
preciso tambm atuar como um empreendedor da sua clula de trabalho. Este o novo perfil do profissional de TI, que no se limita apenas em solucionar problemas e, sim, em analisar o contexto para eliminar a causa raiz. Dessa maneira, qualquer colaborador do time de TI pode agregar valor ao negcio com solues duradouras. Para os prximos trabalhos de pesquisa o autor deseja se aprofundar no estudo de metodologias e padres da gesto de servios aplicados a TI assim como o ITIL(V3), o Lean Six Sigma e a ISO 20000.
68
Bibliografia
BANUELAS, R. and ANTONY, J. (2003) 'Going from six sigma to design for six sigma: an exploratory study using analytical hierarchy process', TQM Magazine 15, 5: 334-44 CMU. CMU/SEI-2001-TR-034 Appraisal Requirementes for CMMI, Version 1.1 (ARC) December/2001. COLLINS, James C. Empresas feitas para vencer / traduo de Maurette Brandt. Rio de Janeiro: Elsevier, 2001 DEMING, W. Edwards (2000). The New Economics for Industry, Government, Education - 2nd Edition. MIT Press. FERNANDES, A. Aragon; ABREU V. Ferraz. Implantando a governana de TI : da estratgia viso dos processos e servios. Rio de Janeiro: Brasport, 2006. ISO. ISO/IEC 9126:1991: Information Technology Software product evaluation Quality characteristics and guidelines for their use. International Organisation for Standarisation. IT Governance Institute. COBIT 4.0, Rolling Meadows, 2005. KAPLAN, Robert S.; NORTON, David P. The Balance Scorecard: translating strategy into action. Boston, Harvard Business School Press, 1996. OGC. ITIL Service Support book Verso 2.1 (2000) OLIVEIRA, Srgio Luiz Ferreira Artigo: Mais Controles e Mais Servios. Revista CIO, IDG Brasil Ed. Maio, 2007. PANDE, Peter S.; NEUMAN, Robert P.; CAVANAGH, Rolan R. Estratgia Seis Sigma: como a GE, a Motorola e outras grandes empresas esto aguando seu desempenho. Rio de Janeiro, Qualymark, 2001. PIZZINATTO, Nadia Kassouf Artigo: Processo de mudana organizacional: estudo de caso do Seis Sigma. Revista da FAE, Maio, 2005. SHIBA, S.; GRAHAM, A.; WALDEN, D. A new american TQM: four practical revolutions in management. Portland: Productivity Press, 1993. WEILL, Peter.; ROSS W. Jeanne. IT Govenance: How top performers manage IT decision rights for superior results. Boston, Harvard Business School Press, 2004. WERKEMA, Maria Cristina Catarino Criando a Cultura Seis Sigma. Nova Lima, MG: Werkema Ed., 2004.
69
Webliografia
DMR Consulting. Disponvel em http://www.drm-consulting.com.br. Acesso em: 23/05/2007 Gartner Group. Disponvel em http://www.gartner.com. Acesso em: 23/05/2007 IBGC Instituto Brasileiro de Governana Corporativa. Disponvel em: http://www.ibgc.org.br. Acesso em: 26/06/2007 Implementao de programas de qualidade: um survey em empresas de grande porte no Brasil. Disponvel em: http://www.scielo.br/scielo.php?pid=S0104-530X2006000200003&script=sci_arttext. Acesso em 15/05/2007. ITIL V3 Launch. Disponvel em: http://www.itilv3launch.com/Files/ITIL-V3-Roadshow-Final2.pdf. Acesso em: 29/06/2007. ISACA (Information Systems Audit and Control Association). Disponvel em http://www.isaca.org. Acesso em 26/06/2007. ISIXSIGMA. Disponvel em: http://www.isixsigma.com/library/content/c020729a.asp. Acesso em: 08/06/2007. ISO 20000 White Paper: BMC Software. Disponvel em:
http://documents.bmc.com/products/documents/49/68/64968/64968.pdf. Acesso em: 30/06/2007 ITSMF Brasil IT Service Management Forum Brasil. Disponvel em: http://www.itsmf.com.br. Acesso em: 23/06/2007. ITSMF International The IT Service Management Forum. Disponvel em: http://www.itsmf.org. Acesso em: 23/06/2007. Lean Six Sigma, a marriage made in heaven? Disponvel em:
http://www.webmags.co.uk/mag.aspx?magcode=SixSigmaCity_01. Acesso em 01/06/2007 Project Management Institute (PMI). Disponvel em http://www.pmi.org. Acesso em 01/06/2007 Six Sigma for Service. Disponvel em: http://www.microsoft.com/business/momentum/content/article.aspx?contentId=737. Acesso em: 25/05/2007. The IT Service Management Forum UK (itSMF). Disponvel em: http://www.itsmf.co.uk. Acesso em: 28/06/20070
70

Monografia - Alexandre Dellai

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Monografia - Alexandre Dellai

Caricato da

Copyright:

Formati disponibili

ALEXANDRE DELLAI SCHLIEPER

APLICAO DA METODOLOGIA SIX SIGMA NA REA DE TI EM EMPRESAS DE SERVIOS

ALEXANDRE DELLAI SCHLIEPER

APLICAO DA METODOLOGIA SIX SIGMA NA REA DE TI EM EMPRESAS DE SERVIOS

Orientador: Prof. Dr. Alexandre Campos Silva

2.1 Definio ................................................................................................................ 8 2.2 Six Sigma ............................................................................................................... 9

4.5 Analyze (Analisar) ............................................................................................... 48

4.6 Improve (Melhorar).............................................................................................. 51 4.7 Control (Controlar)............................................................................................... 52 V

5 ESTUDO DE CASO: TICKET ACCOR SERVICES............................................................... 55

1.3 Mtodo de pesquisa

1.4 Estrutura do trabalho

2.2 Six Sigma

Figura 1 - Mtrica do Six Sigma

Figura 2 Comparao Um Sigma vs. Seis Sigma

Figura 4 Exemplos de performance na escala Six Sigma

Defeitos por milho (ppm) 308.537 66.807 6.210 233 3,4

Percentual conforme 69,15 93,32 99,3790 99,97670 99,999660

Custo da no qualidade (% do faturamento da empresa) No se aplica 25 a 40% 15 a 25% 5 a 15% < 1%

3 A IMPORTNCIA DA GOVERNANA CORPORATIVA NAS OPERAES E NO DESENVOLVIMENTO DE SISTEMAS DE TI

(Fernandes e Abreu, 2006)

Figura 5 Framework Governana Corporativa / Governana de TI

Figura 7 Domnios do Cobit no Framework

Figura 8 Domnio Planejamento e Organizao

Figura 9 Domnio Aquisio e Implementao

Figura 10 Domnio Entrega e Suporte

Figura 12 Cubo Cobit

Confidentiality Informao sensvel deve ser protegida de acesso no autorizado.

3.2 Importncia do ROI

Figura 13 Seleo de Projetos 21

Figura 15 Relacionamento entre Processos Suporte a Servios

Figura 16 Relacionamento entre Processos Entrega de Servios

3.6 BSC Balanced Scorecard

Figura 20 Mapa Estratgico: Desenvolvimento de Negcios

3.7 ISO 27000

Figura 21 Modelo PDCA aplicado ao ISMS

3.8 Conceito do Portfolio de TI

Agrupamento de projetos alinhados com os objetivos de Negcios.

Conjunto de atividades alinhadas ao oramento e cronograma.

Atividades de TI Capacidades bsicas (especificaes, codificao, testes, integrao,

Figura 22 Derivao do Portfolio de TI

3.9 ISO 20000

Figura 23 Processos de Gesto de Servios ISO 20000

Figura 24 Core Structure ITIL V3

4 CONHECENDO SEIS SIGMA E O DMAIC

Figura 25 O segredo do sucesso do Six Sigma

Figura 26 Mtodo DMAIC

4.1 Fatores Crticos de Sucesso

4.2 Como Selecionar Projetos Six Sigma

Figura 27 Matriz de seleo de projetos Six Sigma

Figura 28 DMAIC detalhado

4.3 Define (Definir)

Figura 29 Exemplo de documento Project Charter

4.4 Measure (Medir)

4.4.1 Diagrama de Pareto

Figura 30 Diagrama de Pareto

4.4.2 Lista de Verificao

Figura 31 Lista de Verificao

Figura 32 Exemplo de Histograma

4.4.4 Diagrama de Disperso

Figura 33 Exemplos de Diagramas de Disperso

4.4.5 Grfico Linear

Figura 34 Exemplo Grfico Linear

4.4.6 Grfico (Carta) de Controle

Figura 35 Exemplo de Grfico de Controle