Governança de TI: Aspectos Gerenciais

Governança de TI: Aspectos Gerenciais Governança de TI: Aspectos Gerenciais 1

Governança de TI: Aspectos Gerenciais Governança de TI: Aspectos Gerenciais Governança é a forma como a estrutura organizacionalestá definida (papéis, direitos e responsabilidades), como as relações entre as diversas partes ocorrem (processos e práticas) e como os recursos são administrados e monitorados para que atinjam as metas estabelecidasentre a organização, seus colaboradores e principalmente clientes e como seus resultados são auditados e reportados. 2

Governança de TI: Aspectos Gerenciais Governança Corporativa... é o conjunto de processos, costumes, políticas, leis, regulamentos e instituições que regulam a maneira como uma empresa é dirigida, administrada ou controlada (http://www.profissionaisti.com.br) Governança de TI: Aspectos Gerenciais 3

Governança de TI: Aspectos Gerenciais A Governança de TI tem por objetivo administrar e controlar os recursos de TI com a estratégia de alinhar os processos e metas do negócio aos seus. Governança de TI: Aspectos Gerenciais 4

Governança de TI: Aspectos Gerenciais Ogerenciamento de serviços de TI tem por objetivo prover um serviço deti com qualidade e alinhado às necessidades do negócio, buscando sempre uma redução de custos a longo prazo. (http://pt.wikipedia.org) Governança de TI: Aspectos Gerenciais A Governança de TI está mais interessada em o que fazer?, já o Gerenciamento de Serviços de TI em como fazer? e tudo isso com o suporte de processos, frameworks, como por exemplo, o COBIT, o ITIL, o PMBOK e o CMMI. (http://www.profissionaisti.com.br) 5

Frameworks para a implementação de processos de Governança e Gerenciamento de TI Frameworks: COBIT -The Control Objectives for Information and related Technology 6

COBIT -The Control Objectives for Information and related Technology O COBIT é um framework de boas práticas de gestãoem tecnologia de informação, mantido pelo ISACA Information Systems Audit and Control Association). O COBIT disponibiliza algumas ferramentas, objetivos de controle, mapas de auditoria, técnicas de gerenciamento, métricas para avaliação dos resultados(key Performance Indicators KPI, Key Goal Indicators KGI e Critical Success Factors CSF). (http://www.isaca.org) COBIT A origem: ISACA & ITGI O ISACA -Information Systems Audit and Control Association, nasceu em 1967 para estabelecer uma fonte centralizada de informações e guias para auditoria de sistemas. Em 1976, constitui uma fundação para pesquisa e estudos sobre a governança e controles de TI, que posteriormente, em 1998 se torna o ITGI Information Technology Governance Institute que auxilia os líderes à alinhar seus objetivos de TI aos de negócios, entre outras atividades co-relacionadas. (http://www.isaca.org) (http://www.itgi.org) 7

COBIT A estrutura O COBIT possui quatro domínios com dois objetivos cada e 34 processos. Os domínios são: - Planejar e Organizar - Adquirir e Implementar - Entregar e Manter - Monitorar e Avaliar (http://www.isaca.org) Frameworks: ITIL Information Technology Infrastructure Library 8

ITIL Information Technology Infrastructure Library O ITIL é o framework mais adotado no mundo para ITSM IT Service Management (Gerenciamento de Serviços de TI), ele é utilizado para a identificação, planejamento, entrega e suporte de serviços de TI para o negócio, que aliás, ele defende que estejam sempre alinhados. O ITIL descreve as melhores práticas para ITSM e provê um framework para a governança de TI. (https://www.itil-officialsite.com) ITIL A história A primeira versão do ITIL foi publicada entre 1989 e 1995 no Reino Unido por solicitação do CCTA Central Computer and Telecommunications Agency, hoje incluído no OGC Office of Government Commerce. O objetivo foi o de estabelecer um conjunto de processose procedimentos gerenciais, organizados em disciplinas e que alcançasse o alinhamento estratégico com os negócios. Desta forma, o ITIL busca promover a gestão com foco no cliente e na qualidade dos serviços de TI. (https://www.itil-officialsite.com) 9

ITIL A história (continuação) Na década de 90, o ITIL foi reconhecido como um padrão e assim criada a versão 2, com 7 volumes e que se tornou base para a BS 15.000 e anexo da ISO 20000. Em 2007 foi lançada a versão 3 em 5 volumes. (https://www.itil-officialsite.com) ITIL O framework 10

ITIL Service Support & Service Delivery Os processos do Service Support são: Incident Management; Problem Management; Configuration Management; Change Management; Release Management; Os processos do Service Delivery são: Service Level Management/SLM; Availability Management; Capacity Management; IT Service Continuity Management. (https://www.itil-officialsite.com) Frameworks: CMMI Capability Maturity Model Integration (CMMI-DEV v 1.1) 11

CMMI Capability Maturity Model Integration O CMM foi desenvolvido pelo SEI Software Engineering Institute (Carnegie Mellon) por solicitação do governo americano em 1986, como um guia para melhoria dos processos de software. No ano seguinte, o DoD Department of Defense, solicitou um modelo de avaliação da maturidade no processo de desenvolvimento de software e em 1991 surge o SW-CMM. (https://www.isdbrasil.com.br) O Modelo tem como objetivo estabelecer um conjunto de melhores práticas. (https://www.wikipedia.org) CMMI Capability Maturity Model Integration 12

CMMI Continuous View CMMI Staged View 13

CMMI Áreas Chave de Processo (KPA Key Process Areas) Nível 1: Inicial ( heróico ; Ad-hoc): Não possui áreas de processo. Nível 2: Gerenciado REQM (Requirements Management) PP (Project Planning) PMC (Project Monitoring and Control) SAM (Supplier Agreement Management) MA (Measurement and Analysis) PPQA (Process and Product Quality Assurance) CM (Configuration Management) (https://www.sei.cmu.edu) CMMI Áreas Chave de Processo (KPA Key Process Areas) Nível 3: Definido RD (Requirements Development) TS (Technical Solution) PI (Product Integration) VER (Verification) VAL (Validation) OPF (Organizational Process Focus) OPD (Organizational Process Definition) OT (Organizational Training) IPM (Integrated Project Management) RSKM (Risk Management) DAR (Decision Analysis and Resolution) (https://www.sei.cmu.edu) 14

CMMI Áreas Chave de Processo (KPA Key Process Areas) Nível 4: Quantitativamente gerenciado OPP (Organizational Process Performance) QPM (Quantitative Project Management) Nível 5: Otimizado OID (Organizational Innovation and Deployment) CAR (Causal Analysis and Resolution) (https://www.sei.cmu.edu) CMMI SCAMPI -Standard CMMI Appraisal Method for Process Improvement O Modelo possui um método para avaliar o nível de maturidade e capabilidade do processo, identificando seus pontos fortes e fracos para melhoria contínua. O método, chamado de SCAMPI, possui 3 classes de avaliação: A, B e C (onde o A é o mais rigoroso) (https://www.sei.cmu.edu) 15

CMMI Tempo de evolução de nível CMMI Benefícios CMMI 2007 CMMI 2010 (https://www.sei.cmu.edu) 16

Frameworks: PMBOK -Project Management Body of Knowledge PMBOK - Project Management Body of Knowledge O PMBOK Project Managment Body of Knowledge ( conjunto de conhecimentos em gerenciamento e projetos ) é um livro publicado pelo PMI Project Management Institute (Filadélfia, 1969), que é uma entidade sem fins lucrativos, voltada para o gerenciamento de projetos. As práticas contidas no guia são aplicáveis a todo tipo de indústria. (http://www.pmiorg) 17

PMBOK - Project Management Body of Knowledge O PMBOK identifica um subconjunto de um conjunto de conhecimentos, reconhecidos como boas práticas em gerenciamento de projetos, o que não significa que devem ser aplicadas para qualquer tipo de projeto. O guia estabelece um vocabulário comum e descreve de forma organizada o trabalho a ser realizado durante um projeto. (http://www.wikipedia.org) PMBOK O conjunto de conhecimentos 1. Definição do ciclo de vida e da organização e da organização de um projeto 2. Descrição dos grupos de processo: 2.1. Iniciação 2.2. Planejamento 2.3. Execução 2.4. Monitoramento e Controle 2.5. Encerramento (http://www.pmi.org) 18

PMBOK O conjunto de conhecimentos 3. Descrição das áreas de conhecimento, que consistem no gerenciamento de: 3.1. Integração do projeto 3.2. Escopo 3.3. Tempo 3.4. Custos 3.5. Qualidade 3.6. Recursos Humanos 3.7. Comunicações 3.8. Riscos 3.9. Aquisições (http://www.pmi.org) PMBOK O conjunto de conhecimentos 19

PMBOK O OPM3 O OPM3-Organizational Project Management Maturity Model, foi publicado pelo PMI em 2003 e segmenta o gerenciamento de projeto em três áreas: projetos, programas e portfólios. O OPM3 é um corpo de conhecimento sobre as melhores práticas de gerenciamento de projetos e permite que as organizações avaliarem e melhorarem a sua maturidade e assim obterem benefícios estratégicos e uma potencial vantagem competitiva. (http://www. itgovernance.co.uk/pmbok.aspx) E se não gerenciarmos os projetos corretamente? 20

Standish Por quê os projetos falham? PMI Por quê os projetos falham? Amostragem com 300 empresas: 76% Por problemas na comunicação 71% Pelo não cumprimento dos prazos 70% Culpam as mudanças de escopo 46% O investimento variou de R$ 1M à R$ 10M 58% Não possuem uma área de PM 20% Reportaram alguma resistência (problema cultural) 18% Raramente planejam (http://www.diegororiz.com.br/2010/05/falhas-na-gestao-de-projetos-traz-prejuizos-paraas-empresas/) 21

Standish Falhas em projetos Pesquisa do Standish Group dos EUA para projetos de TI: - Ficaram 189% acima do orçamento -Atrasaram 222% -Entregaram apenas 61% do acordado (funcionalidades) -Apenas 16% dos projetos foram entregues no prazo e no orçamento Standish Falhas em projetos Standish Chaos Reports 2009 : -24% Falham totalmente (cancelados ou entregues e nunca utilizados) -44% Foram entregues atrasados, com menos funcionalidades ou acima do custo estimado -32% São bem sucedidos - Defeitos em software custam US$ 60B/ano 22

Standish Falhas em projetos Gartner Falhas em projetos Gartner Symposium Emerging Trends / ITxpo 2008, maio: -90% dos projetos corporativos do mundo virtual vão falhar nos próximos 18 meses 23

Galorah Falhas em projetos -Aplicações mal definidas (falta de comunicação entre negócios e TI) contribui para 66% dos fracassos dos projetos e custam US$ 30B / ano para as empresas americanas (Forrester Research) -60% -80% das falhas de projeto resultam de pobre levantamento de requisitos, análise e gestão (Grupo Meta) -50% são retirados de produção (Gartner) -40% dos problemas são encontradas por usuários finais (Gartner) -25% -40% dos gastos em projetos são re-trabalho (Carnegie Mellon) -Até 80% dos orçamentos são consumidos para corrigir problemas causados pelas próprias organizações (Dynamic Markets Limited 2007) COBIT, ITIL, CMMI, PMBOK... Com tudo isso, teremos sucesso? 24

Se não messo, não gerencio É preciso definir Indicadores! 25

Indicadores O que é? Segundo a Organização de Cooperação e Desenvolvimento Econômico (OCDE), um indicador é: (...) uma ferramenta de avaliaçãoentre outras; para captar-se todo o seu sentido, devem ser interpretados de maneira científica e política. Devem, com a devida freqüência, ser complementados com outras informações qualitativas e científicas, sobretudo para explicar fatores que se encontram na origem de uma modificação do valor de um indicadorque serve de base a uma avaliação (OCDE, 2002, p. 204). Ainda no mesmo documento encontra-se outra definição de indicador: (...) parâmetro, ou valor calculado a partir dos parâmetros, fornecendo indicações sobre ou descrevendo o estado de um fenômeno, do meio ambiente ou de uma zona geográfica, de uma amplitude superior às informações diretamente ligadas ao valor de um parâmetro. (OCDE, 2002, p. 191). Indicadores O que é? Também a European Environment Agency (EEA) refere frequentemente os indicadores nos seus relatórios. Define-os como sendo: (...) uma medida, geralmente quantitativa, que pode ser usada para ilustrar e comunicar um conjunto de fenómenos complexos de uma forma simples, incluindo tendências e progressos ao longo do tempo (EEA, 2005, p. 7). Referido pelo mesmo organismo mas, agora citando o Internet Engineering Task Force (IETF): Um indicador fornece uma pista para uma matéria de largo significado ou torna perceptível uma tendência ou fenómeno que não é imediatamente detectável. Um indicador é um sinal ou sintoma que torna algo conhecível com um razoável grau de certeza. Um indicador revela, dá evidência, e a sua significância estende-se para além do que é actualmente medido a um grande nível deinteresse do fenómeno (IETF referido por EEA, 2005, p. 7). 26

Indicadores Como definir 1.Definir o quê deseja medir e espera deste indicador 2. Definir o por quê deste indicador e o quê faremos com ele (ações) 3. Definir a meta esperada 4. Definir o método de cálculo 5. Definir a freqüência da medição 6. Definir o responsável pela medição 7. Definir qual será a interpretação (definição operacional) Agora teremos sucesso? 27

Competência: habilidades + conhecimento + quem sou É necessário o apoio da alta administração, o engajamento do pessoal operacional, e todos alinhados com o negócio. Assim, a probabilidade de uma governança de sucesso aumentam 28

Como tudo acontece? Governança de TI: Aspectos Gerenciais Visão Missão Estratégia (alinhamento com o negócio) Itens de Ação (atividades e projetos) Indicadores Balanceamento das demandas x capacidade (recursos limitados) Priorização das demandas Medir, Controlar, Gerenciar, Governar 29

Perguntas? Muito obrigado! (msoprani@terra.com.br) 30