.

Gestão de Projetos em P&D: Contribuição das Melhores Práticas do Mercado

2011-05-11T05:10:00.001-07:00

Um Projeto de Pesquisa & Desenvolvimento (P&D) não é muito diferente dos outros projetos no que se refere à sua gestão. É temporário, o que significa dizer que tem um início e um fim bem definidos. É um meio para se introduzir mudanças. Envolve pesquisadores, analistas e outros colaboradores com diferentes habilidades trabalhando juntos para introduzir uma mudança com impacto externo. É único, ou seja, uma unidade de pesquisa pode realizar projetos similares, porém, cada projeto reúne fatores e características que o tornam singular. Por fim, todo projeto de P&D tem um grau de incerteza que poderá trazer ameaças ou oportunidades que devem ser gerenciadas. Na edição de março/2011, a revista científica do PMI, Project Management Journal, publicou um paper sobre Projetos em P&D, com foco na indústria farmacêutica, mas que serve para os demais setores. Conforme o artigo, a area de P&D é organizada por meio de PDPs simultâneos (Product Development Projects). Significa uma especial atenção em manter um nível adequado de portfolio de projetos em diferentes estágios de desenvolvimento. Nesse aspecto, a alocação efetiva de recursos e uma gestão eficaz dos projetos tornam-se fundamentais em todo o processo. Bem, um Projeto de P&D conta para sua viabilidade com um anteprojeto de Estudo Técnico-Econômico (Techno-Economic Analysis) ou um business plan. Essas informações são importantes para projetos de financiamento, servindo de justificativas para investidores públicos ou privados. Conforme Cassarrotto (2009), um anteprojeto tem por finalidade levantar os parâmetros do empreendimento industrial que conduzem à uma alternativa ótima, abrangendo: a) Estudo de mercado, visando definir produtos , faixas de mercado e condições de comercialização (o quê, quanto, a quem, onde e de que forma comercializar); b) Estudo de localização, visando definir onde produzir; c) Estudo de engenharia, visando definir a tecnologia e caracterizar o processo produtivo, ou seja, como produzir; d) Estudo de tamanho, visando definir escala e nível econômico, ou seja, quanto produzir; e) Estudo econômico-financeiro, visando definir investimentos e recursos financeiros, ou seja, quanto e como investir.

Um processo de P&D envolve a concepção da idéia ou pesquisa básica, avaliação de viabilidade, busca de financiamentos, aquisição ou fabricação de tecnologias, desenvolvimento do produto, testes de laboratórios, bancadas, plantas pilotos, fabricação do produto final ou transferência da tecnologia e, por fim, comercialização do produto no mercado. Nesse processo, uma gestão eficaz de projetos é fundamental para o sucesso da pesquisa desenvolvida. Melhores práticas em Project and Portfolio Management e também de Project Office podem ajudar. O uso de práticas como o PMBoK, Prince2, IPMA e Scrum pode e deve ser incentivado, principalmente em entidades de pesquisa não projetizadas. Segundo o Dr. Harold Kerzner, as melhores práticas em gestão de projetos são definidas internamente na empresa, observando-se o que existe no mercado e também o que funcionou bem e o que tem maior probabilidade de funcionar bem no futuro se for repetido em todos os projetos e com vários clientes. Vejamos como ...

As Melhores Práticas em Gestão de Projeto são atividades ou processos reutilizáveis que continuamente agregam valor ao produto final dos projetos.
Dr. Harold Kerzner

O PMBoK, desenvolvido pelo PMI – Project Management Institute, não é uma metodologia, mas sim um guia com as melhores práticas que podem ser usadas na maioria dos projetos, inclusive em P&D. O PMBoK trabalha com o conceito de restrição tripla, ou seja, escopo, custo e prazo. Se diminuirmos o prazo do projeto, teremos um aumento de custo ou/e uma diminuição do escopo. Se diminuirmos o custo, teremos um aumento de prazo ou/e diminuição do escopo e, se aumentarmos o escopo, teremos um aumento de prazo ou/e um aumento de custos. O ciclo de vida do PMBoK está dividido nos seguintes processos: Iniciação, Planejamento, Execução, Monitoração/Controle e Encerramento. A sua base de conhecimento abrange o gerenciamento das seguintes áreas: Integração, Escopo, Tempo, Custo, Qualidade, RH, Comunicação, Riscos e Aquisições. Utiliza um método para seleção de projetos por meio de modelos com abordagem econômica ou matemática, realizado no início do projeto para justificá-lo.

O Prince2 é parte de um conjunto de guias desenvolvidos pelo OGC (Office Government Office) do Reino Unido. Tem como objetivo auxiliar organizações em gestão de projetos, programas e portfolio. É considerado como um framework, podendo ser adaptado a qualquer tipo de projeto, incluindo P&D. Os quatro elementos do Prince2 são: Princípios, Processos, Temas e Ambiente. O Prince2 acrescenta mais três restrições envolvidas em um projeto: Qualidade, Riscos e Benefícios, além de Custos, Prazo e Escopo. Os seus Princípios abrangem uma boa justificativa para o projeto (business case contínuo em todo o projeto), aprendizado por meio da experiência, papéis e responsabilidades, gerenciamento por estágios (técnico e gerencial), gerenciamento por exceção (por meio de níveis de tolerância para cada restrição ao longo de todo o projeto), foco no produto e adaptação (tailoring, por se tratar de um framework). Os temas do Prince2 contemplam Business Case, Organização, Qualidade, Planos, Riscos, Mudanças e Progresso. O ciclo de vida inclui Starting Up a Project (SU), Initiating a Project (IP), Managing a Staging Boundary (SB) e Closing a Project (CP).

O IPMA (International Project Management Association) é um padrão europeu, com sede na Suíca e associações locais em 45 países. Trata-se de um modelo de gestão de projetos baseado em competências (níveis de conhecimento e competências necessárias para execução de cada processo). Apresenta um foco muito grande na verificação das Competências Técnicas, Contextuais e Comportamentais. O código de melhores práticas é o ICB (IPMA Competence Baseline 3.0). Outro detalhe é que o ICB possui alguns processos complementares ao PMBoK e Prince2, como por exemplo Financiamento do Projeto, Aspectos Comportamentais do Gerente do Projeto, Gestão de Conhecimentos, Gestão de Meio-Ambiente, Gestão de Aspectos Legais e Gestão de Tecnologia da Informação. A sua visão é mais internacional, uma vez que cada país possui o seu guia de melhores práticas em Project Management, conservando o núcleo do ICB.

O Scrum é uma metodologia de gestão ágil de projetos (APM – Agile Project Management). Consolida conceitos de Lean, desenvolvimento iterativo e de Gestão de Conhecimento de Nonaka & Takeuchi. É uma prática de gestão de projetos baseada em times pequenos e auto-organizados. Parte de uma lista inicial de necessidades que precisam ser priorizadas (o que deve ser realizado primeiro) e produzidas para que a visão do produto seja atingida. As necessidades priorizadas entram em um ciclo denominado Sprint que deve durar de 2 a 4 semanas, dependendo do tamanho do projeto. Cada Sprint é uma iteração que segue um ciclo (PDCA) e entrega incremento de produto pronto. O time do Scrum é formado por um Product Owner (ROI e Necessidades do Cliente), Scrum Master (Remove impedimentos do time e garante o uso correto do scrum) e um time multi-discplinar, auto-gerenciado e que produz um produto com qualidade e valor para o cliente dentro do Sprint. Um aspecto importante é a reunião diária de 15 minutos também chamada de Daily Meeting ou Stand-up Meeting. As ferramentas mais utilizadas são o Kanban (onde são visualizados o To Do, Doing, Done, Alerts e Improve). E o Burnout para acompanhamento dos projetos.

Bem, e quanto aos benefícios do uso dessas práticas em projetos de P&D. Existem vários pontos de contribuição. Citamos algumas delas ... O Prince2 apresenta algumas características que facilitam a gestão de projetos em P&D. A principal delas é o conceito de Business Case. Pelo Prince2, o Business Case de um projeto é desenvolvido no início do projeto e é mantido ao longo de seu ciclo de vida, sendo formalmente verificado por Comitê ou Investidor a cada ponto chave de decisão, e confirmado durante o período em que os benefícios são realizados. A Gestão Qualititativa e Quantitativa de Riscos no Prince2 e no PMBoK são referências na identificação, avaliação e controle das incertezas em projetos. Por se tratar, na sua maioria, de projetos de longo prazo, o conceito de proximidade do risco (além de probabilidade e impacto) inserido no Prince2 é outro ponto a ser considerado em projetos de P&D. O Gerenciamento de Exceção do Prince2 é um fator importante para P&D. Trata-se da criação e gestão de tolerâncias para cada restrição do projeto (riscos, prazos, custos, qualidade, escopo e benefícios). Caso no estágio ou projeto exista uma previsão de desvio além das tolerâncias acordadas, o projeto ou estágio está em exceção e deve ser escalado para o comitê ou investidor. Um aspecto crítico em projetos de P&D são as aquisições de tecnologias, matérias-primas e equipamentos. Envolve contratação de produtos e serviços de terceiros e Make ou Buy Analysis. No PMBoK, o gerenciamento de aquisições fornece melhores práticas em gestão de aquisições e de contratos, incluindo planejamento de contratações na fase inicial do projeto de P&D, solicitação de propostas (RFP, RFI, RFQ etc.), Métodos de seleção de fornecedores e também a gestão e encerramento de contratos.

Já o IPMA fornece o processo de Custos e Financiamento, onde são abordados aspectos relacionados de funding para a realização do projeto e também a Gestão do Conhecimento, imprescindível em projetos de P&D. No IPMA, consiste em identificar os conhecimentos relevantes, colaboração, transferência e gestão de lições aprendidas. Também abrange a responsabilidade do Project Manager no tema KM. Apesar da maioria dos projetos de P&D ser de longo prazo, em algumas situações o uso do Scrum mostra-se eficiente, principalmente pela questão envolvimento dos colaboradores. Pode ser integrado com as metodologias mais tradicionais como o PMBoK e Prince2. A utilização do Quadro Kanban fornece uma gestão visual para as atividades de P&D, como também as reuniões diárias (stand-up meeting). Utilizando-se post-its pode-se indicar prioridades ou algo a ser observado. Finalmente, recomenda-se o desenvolvimento de uma Metodologia de Gerenciamento de Projetos e Portfolio em P&D (MGPP), aplicável às pesquisas de P&D utilizando o melhor das quatros práticas apresentadas.

Uma Abordagem de Lean Six Sigma em TI

2011-01-16T05:12:00.000-08:00

As raízes do Lean e do Six Sigma em manufatura não deixam claro como aplicar essas ferramentas em serviços. Há algum tempo esse paradigma foi quebrado e o uso do LSS em serviços, incluindo tecnologia da informação, é cada vez maior. O desafio é utilizar a velocidade Lean e a qualidade Six Sigma para melhoria dos serviços. Segundo Michael George, um dos gurus da área em seu livro Lean Six Sigma for Services, o Six Sigma enfatiza a necessidade de reconhecer oportunidades e eliminar defeitos definidos pelo cliente. Reconhece que a variação prejudica nossa capacidade de entregar serviços de alta qualidade de forma confiável. Requer decisões baseadas em dados e incorpora um abrangente conjunto de ferramentas da qualidade sob uma estrutura DMAIC ou DMADV para a solução eficaz de problemas. Quando corretamente aplicado, promete e entrega US$ 500 mil ou mais de melhoria no lucro operacional por Black Belt por ano. Já o Lean focaliza na maximização de velocidade do processo. Oferece ferramentas para a eliminação de desperdícios, análise de fluxo de processo (VSM) e tempos de atrasos em cada atividade do processo. Centra na separação do trabalho “adicionador de valor” do “não-adicionador de valor” com ferramentas para eliminar as causas-raiz de atividades não-adicionadoras de valor e o seu custo. Oferece métodos para quantificar e solucionar os desperdícios mais comuns (produção em excesso, transporte, inventário, processamento em excesso, correção, espera, movimentação, não uso do talento etc.) e eliminar o custo da complexidade.

"Um dos pilares do Lean Six Sigma é que complexidade desnecessária adiciona custos, tempo e um enorme desperdício."

Michael George

Bem, e quanto à aplicação do LSS a serviços. Existem algumas razões que justificam o seu uso, como por exemplo: a) Processos de serviços são geralmente processos lentos, passíveis de má qualidade, que aumenta custos e reduz a satisfação de cliente; b) Processos de serviços são lentos, porque há trabalho em processo (WIP – Work in Process) em demasia, o que é resultado de complexidade desnecessária na oferta do serviço e c) Excessos potenciais de variações na produtividade, qualidade e na entrega dos serviços. Em serviços, porém, deve-se tomar cuidado para não usar “um canhão para matar um mosquito”. Às vezes, um projeto de MASP (Metodologia de Análise e Solução de Problemas), PDCA, 8D ou outros podem ser mais rápido para atacar um problema, mesmo de forma estatística. No seu livro Lean Office, Tapping e Shuker salientam que o Lean aplicado nas áreas administrativas (100% serviços) traz resultados surpreendentes e reais. Essas áreas são negligenciadas, apesar de representar uma boa parte dos custos envolvidos para satisfazer a demanda de um cliente.

A GE Capital foi um dos primeiros “cases” de aplicação de Lean Six Sigma em serviços. Os problemas de produtividade, reclamações de clientes e altos custos por cartão de crédito foram atacados por uma equipe de Black Belts, Green Belts e White Belts. Ocorreu redução do número de faturas erradas, o cliente passou a não precisar ligar para a GE solicitando correções e houve também queda de gastos com as verificações solicitadas pelos clientes. No Brasil, um “case” famoso é o de um grande banco brasileiro para Redução no tempo de processamento de admissão de novos colaboradores para o Conglomerado. Como resultado o Lead Time (LT) reduziu em 80%, saindo de 26 para 4,1 dias úteis em média, com melhoria de 97,7% das admissões em até 8 dias úteis. Em serviços de TI, existem cases de aplicação de Lean Six Sigma em provedores de TI nos EUA e Brasil, como por exemplo melhorar a produtividade por meio de ações relacionadas à gestão e implantação de novas ferramentas para apoio ao processo produtivo de software, incluindo produtividade, reuso, agilidade e redução de custos.

Todas as ferramentas do Lean Six Sigma, podem ser utilizadas em serviços. Algumas podem ser adaptadas. Um exemplo de adaptação é o Lead Time (LT). Trata-se da relação entre o trabalho em processo e o índice médio de conclusão. Em serviços de TI, podemos traduzir como a relação entre backlog de demandas/incidentes e a capacidade de solução da equipe. A redução do LT deve ser uma meta sempre.

"Influenciar as entradas das demandas/incidentes, investir em aumento de produtividade, redução da complexidade e foco no RCA (Root Cause Analysis) são alternativas para redução do Lead Time em Serviços de TI. "

Outra adaptação sugerida é que o DPMO (quantidade de defeitos por unidade) pode substituir o Cpk (índice de capacidade em processo). No entanto, todas as ferramentas de LSS podem ser utilizadas em serviços a exemplo de CEP, Capacidade, Design de Experimentos, Superfície de Respostas, Testes de Hipóteses, ANOVA, FMEA/FDA, Plano de Controle, MSA, Lead Time, Takt Time, RTY, TOC, Waste Elimination, RCA, Risk Analysis etc.

A revista Quality Progress da ASQ de set/2010 traz em sua capa a matéria “Keep it Simple. For Lean Success, Focus on Fundamentals”. Destaca que Lean Six Sigma aplicado em serviços de TI, tanto de Mercado como no Governo, pode se converter em economias reais, transformar a organização e gerar crescimento do negócio. Em serviços, pessoas e não tecnologias é a chave fundamental para o sucesso do Lean Six Sigma. Eis um bom tema para debate. Muito recente e nos traz vários desafios.

Um Insight em Gestão de Riscos de TI

2010-10-17T06:18:00.000-07:00

Risco não é um conceito novo. A Teoria Moderna das Carteiras e da Diversificação, que se originou do trabalho pioneiro de Henriy Markowitz no inicio da década de 50, visava basicamente a eliminação do risco não sistemático. Logo após, Willian Sharpe introduziu os conceitos de risco e retorno com a precificação de ativos (CAPM). Em linguagem popular: No risk, no fun. Bem, o risco cobre quatro principais grupos: Operacional, Mercado, Crédito e Legal. Nos tempos em que estudava na FIPE / USP (Fundação Instituto de Pesquisas Econômicas) minhas fontes favoritas no assunto eram os livros de Jorion (Value at Risk), Damodaram e também Corporate Finance de Ross, Westerfield e Jordan. Meu professor de Gestão de Investimentos brincava que riscos poderia ser traduzido como desvio padrão. Simples assim. Qualquer medida numérica da incerteza poderia ser chamada de risco. Em outras palavras, o grau de dispersão dos possíveis resultados em termos do valor esperado é uma medida de risco. Já o Coeficiente de Variação indica o risco por unidade de retorno esperado e é obtido pela relação desvio-padrão e a média aritmética da amostra (ou população). Em Finanças Corporativas aprendi também que o Risco Total é a soma do Risco Sistemático ou Conjuntural (não diversificável e que apresenta comportamento do ativo frente a eventos de natureza política, econômica e social) e o Risco Não Sistemático (diversificável e próprio de cada ativo).

Bem, e quanto à Riscos de TI. O Risco em serviço de TI enquadra-se no conceito de Risco Operacional. Riscos Operacionais envolvem riscos de produção, segurança, tecnologia da informação, obsolescência, capacidade, confiabilidade, equipamentos, fraudes, qualificação, regulamentação, requisitos etc. Há algumas décadas atrás não havia uma preocupação maior com esse tipo de risco. Termos regulatórios como a Sarbanes-Oxley, PCI, HIPAA, GxP e Basel II forçaram as empresas a observarem melhor os seus riscos operacionais.

Vamos então para a prática de Gestão de Riscos em TI. A cena é mesma. As ocorrências de problemas em segurança da informação ou de entrega de serviços de TI são escaladas para a alta administração. Contrata-se uma equipe interna ou uma consultoria externa. Realiza-se um processo de risk analysis. Elabora-se um plano de ação para os riscos mais graves e implementa-se os controles necessários, baseado no que foi identificado. Mas, e quanto à gestão contínua dos riscos, o dia-a-dia, como deveria funcionar? alguns frameworks ajudam na rotina diária de gestão de riscos de TI, a exemplo do VAR, ISO 27005, NIST SP800-30, ISO 31000, Risk IT e COSO ERM. Ferramentas ajudam a automatizar (Corporate Metrics, Risk Navigator, CA GRC). Dos modelos, o NIST SP800-30 é um dos mais simples e objetivos para uso em Risk Management.

A gestão diária dos riscos é muito importante. É mais do que um simples risk assessment do que ocorreu, elaboração de um plano de ação e tentativas de colocar em prática o planejado. Em uma matéria na revista HBR de outubro/2009, professores da NYU sugeriram que a gestão moderna de riscos envolve reduzir o impacto daquilo que não entendemos e não criar técnicas sofisticadas para prever o ambiente futuro, baseado em análise do passado. Não vivemos no mundo para o qual o típico manual ou uma norma de gestão de riscos nos prepara. Eventos de baixa probabilidade e alto impacto, impossíveis de prever, são cada vez mais comuns. Por causa de internet e da globalização, o mundo virou um sistema complexo. Em vez de tentar antecipar esses eventos, devíamos reduzir nossa vulnerabilidade a esse tipo de fenômeno. O Gerente de Riscos erra em fazer um risk analysis olhando no retrovisor para enxergar o futuro. Pesquisas da Universidade de Harvard (HBR out/2009), sugerem que eventos passados não guardam relacionamento com os riscos futuros.

Governança, Fundamentos Sólidos de TI e Forte Cultura de Riscos são requisitos fundamentais para uma efetiva Gestão de Riscos.
Isaca Journal, Mar/2010

Em um artigo publicado no ISACA Journal em mar/2010 (edição totalmente dedicada à gestão de riscos), Westerman e Barnier relatam que uma efetiva gestão de riscos compreende um processo de governança de riscos, fundamentos sólidos da TI e também uma cultura em riscos. Essas ações melhoram os fundamentos de controle e gestão de TI e dos riscos. A governança de riscos compreende um conjunto de políticas, processos, indicadores de riscos, auditorias e regras que permitem à organização, comitês e gestores tomarem as decisões corretas sobre os riscos de TI. O comprometimento dos stakeholders presume envolvimento contínuo e provisão de informações de fornecedores, clientes, funcionários e parceiros na Gestão de Riscos. Problemas relacionados a riscos residem em fundamentos imaturos de TI, a exemplo de ausência de controle na gestão de mudanças, testes e release, gestão ineficiente dos ativos, identidades e pessoas ou ausência de um eficiente gerenciamento de ameaças. O uso de práticas e padrões como Cobit, ISO 27001, ITIL / ISO 20000, CMMI, PMBoK e outros ajudam em uma gestão eficiente desses fundamentos.

Já uma cultura de riscos não deve ser considerada apenas como treinamentos em conscientização, mas também liderança, comunicação constante e realização de eventos sobre o tema riscos. Dessa forma todos reconhecerão que o risco faz parte das suas atividades e evitá-los ou mitigá-los é o objetivo. Abre também uma discussão colaborativa sobre o tema riscos e também ajuda no trabalho conjunto para o funcionamento correto dos controles internos. O objetivo é uma gestão eficiente dos riscos, no seu dia-a-dia e também uma melhor gestão de TI. Eis um bom tema para debate.

Gestão Estratégica de Mudanças em TI

2010-08-29T13:48:00.000-07:00

Boa parte das mudanças da área de TI vem de problemas relacionados com incidentes que precisam de resolução definitiva. Nesse aspecto a gestão quase sempre é reativa. Frameworks e normas como o CobiT, ITIL e a ISO 20000 fornecem as melhores práticas. Outras mudanças têm origem em portfolios de projetos alinhados com a estratégia da organização. Frameworks como o PMBok/OPM3 e o Val IT (PM) apoiam os processos. Este post abrange essas mudanças estratégicas. Todo mundo concorda que é preciso mexer na TI quando o ambiente de negócios da empresa impõe mudanças. Mas a idéia de que os ambientes de infraestrutura e de aplicações de TI possam querer mudar só por mudar em geral é vista com ceticismo. Em uma visão proativa, a TI precisa passar por uma “chacoalhada”, seja qual for o cenário externo de negócios da empresa. Bem, qual a real necessidade dessas mudanças estratégicas?

Antes de qualquer coisa, é importante saber um pouco que a criação da estratégia começa com as metas, que vêm em seguida à missão da organização. Um exemplo da meta estratégica para um provedor externo de TI é aumentar sua participação em 30% em serviços de RIMO (Remote Infrastructure Management Outsourcing) no mercado brasileiro até dezembro de 2011. Essas metas não vêm do nada; elas são resultados da análise do ambiente externo (ex. clientes, concorrentes, economia, parceiros, tendências etc.) e do ambiente interno (portfolio, pipeline, tecnologia, cultura, processos, recursos humanos etc.). Neste contexto, as mudanças estratégicas em TI devem acompanhar a estratégia da organização em todos os seus aspectos, não apenas na visão externa (estratégia competitiva), mas também na análise interna, cuja abordagem mais conhecida é a RBV.

A Visão Baseada em Recursos (RBV) tem como foco as competências essenciais que são as atividades que a empresa executa bem em comparação com a concorrência e que trazem valor para os seus clientes. Essas competências são originadas de combinação de recursos tangíveis e intangíveis, considerados estratégicos. Muitos recursos de TI (software, hardware, conhecimentos, processos etc.) fazem parte desses ativos estratégicos. A grande questão é que esses recursos de TI precisam ser combinados com outros recursos dentro da empresa (ex. Recursos de Produção, Vendas etc.) para prover as competências essenciais.

“Quanto mais tempo as coisas forem feitas de um determinado jeito, mais difícil será se adaptar quando o negócio mudar.”

Vermeulen, Phanish e Gulati (Harvard Business Review, Jun/2010).

As competências são, por natureza, dinâmicas para que a empresa se mantenha a frente dos competidores e para que os clientes possam sempre valorizar os seus serviços e produtos. Afinal de contas, os cenários mudam, crises acontecem, oportunidades surgem... Por tabela, os recursos também precisam ser dinâmicos. Sendo assim, devem existir mudanças proativas dentro de TI para manter os recursos sempre estratégicos (pessoas, infra, software, conhecimento, processos etc.). Se o CIO considerar apenas a eficiência operacional, os recursos e capacidades de TI podem resultar em “incompetências essenciais” porque representam atividades na qual a empresa é mais fraca do que concorrentes.

Bem, em se tratando de mudanças estratégicas em TI (proativas, por natureza), a questão principal é saber quando mudar. Um questionário pode ajudar a decidir. O conteúdo dessa questionário dependerá de aspectos a exemplo do tipo do negócio, comunicação, governança entre as áreas da empresa, estrutura, controle e recursos estratégicos da empresa. Provedores de TI (internos e externos) que mudam antes que obrigados a tal não passam pelo processo radical e doloroso de reestruturação. Eis mais um bom tema para debate

Uma Perspectiva de Ecossistema para PD&I

2010-07-09T04:11:00.000-07:00

Há bastante tempo venho pesquisando o tema “Eccossistema de PD&I” (Pesquisa, Desenvolvimento e Inovação). Mais recentemente estudo a inovação aberta, disruptiva, inovação de valor e colaboração em massa. Atualmente, empresas, governos e universidades devem criar redes, desenvolver parcerias e aceitar idéias externas, vindas de outras empresas, governos, universidade ou de profissionais de mercado. Neste post, porém, gostaria de abordar o conceito clássico de ecossistema de PD&I, sob o ponto de vista da colaboração dos três atores principais: Empresas, Governo e Universidade e debater alternativas para o assunto. Estava lendo um livro de Administração Estratégica de Hitt et al e me deparei com um texto interessante: “As oportunidades empreendedoras são condições nas quais novos produtos ou serviços conseguem atender a uma necessidade do mercado. Para serem empreendedoras, as empresas devem desenvolver mentalidades empreendedoras entre seus gerentes e funcionários”. Aproveitei e tentei pesquisar algo relacionado em outro livro bem conhecido: “Empreendedorismo” de Baron & Shane da Case Western / Rensselaer Polytechnic. Os autores demonstram que o processo empreendedor começa, de fato, com o reconhecimento do potencial para algo novo nas mentes de um ou mais indivíduos que, se optarem por desenvolver essas oportunidades, se tornarão empreendedores. A mudança tecnológica é a fonte mais importante de oportunidades. Possibilitam que as pessoas façam as coisas de forma nova e mais produtiva. Os autores citam também outras fontes da inovação como mudança política, regulatória, social ou demográfica.

“As idéias não surgem do nada, elas quase sempre são uma combinação nova de elementos já existentes. O que é novo é a combinação – não os componentes que fazem parte dela.”
Baron & Shane

As idéias não surgem do nada. Steve Jobs já falava que inovação tem a ver com criatividade, com juntar as coisas de formas únicas. Criatividade é apenas conectar as coisas. Quando você pergunta a pessoas criativas como fizeram alguma coisa, elas se sentem um pouco culpadas, porque, na verdade, não fizeram aquilo; elas só viram aquilo. A coisa lhes pareceu tão óbvia, depois de certo tempo, porque conseguiram conectar experiências que tiveram e sintetizar coisas novas. E o motivo pelo qual elas conseguiram fazer aquilo é que tiveram mais experiência ou pensaram mais sobre suas experiências do que outras pessoas.

Bem, e quanto ao Ecossistema de PD&I. Sabemos que a inovação é o principal resultado que as empresas buscam por meio do empreendedorismo e é geralmente a fonte do sucesso competitivo, especialmente em ambientes altamente competitivos, a exemplo do segmento de tecnologia da informação. Sbragia et al no livro “Inovação” (leitura essencial sobre ecossistema de inovação) descrevem que a inovação é um processo sistêmico, que envolve inúmeros autores que atuam segundo lógicas e prioridades distintas, e que só se realiza em um ambiente estimulante e catalisador de competências e iniciativas de cada um. Esta definição tem tudo a ver com ecossistema da inovação. Faz lembrar também do conceito da Hélice Tripla, que foi criada para descrever a cooperação moderna entre os diversos atores do processo de inovação – universidade, indústria e governo. Cada entidade assume, cada vez mais, o papel de outras – as universidades, por exemplo, assumem postura empresarial, licenciando patentes e criando empresas de base tecnológica, enquanto empresas desenvolvem uma dimensão acadêmica, compartilhando conhecimentos entre elas e treinando seus funcionários em níveis cada mais elevados de qualificação (ex. universidade corporativa). Existe então uma formação de redes formadas pelo governo, empresas e universidades.

Por sua vez, para incentivar a inovação dentro das empresas e universidades, o governo exerce um papel fundamental no ecossistema de apoio ao empreendedor. O empreendedorismo pode transformar as economias. O professor Silvio Meira da UFPE/Cesar define a inovação como uma cadeia de valor de investimento empreendedor que tenha inovação como seu alvo principal. Segundo ele, Não se cria empresa inovadora de tecnologia com tecnologia, mas com dinheiro. A principal infraestrutura de inovação do Silicon Valley não é a universidade, nem os empreendedores de garagem ou de dormitório universitário, mas a capacidade inovadora do capital empreendedor. Mas, será o Vale do Silício é um guia ideal para um eccossistema brasileiro. Vejamos ...

Na edição de junho/2010 a revista Harvard Business Review publicou um artigo interessante sobre o tema: “Como lançar uma revolução empreendedora” de Daniel Isenberg do Babson College. O autor sugere nove ações que devem ser integradas num sistema holístico para a criação de um ecossistema de sucesso. Não queira reproduzir o Vale do Silício. A ambição de criar outro Vale do Silício leva muitos governos à frustração e ao fracasso. Ninguém duvida que é o exemplo acabado de ecossistema empreendedor. Porém, o autor afirma que a inveja é um péssimo guia por três razões. A primeira é que, ironia das ironias, nem mesmo o Vale do Silício poderia, hoje, se transformar no que é. Seu ecossistema evoluiu sob circunstâncias únicas: uma forte indústria aeroespacial local, a cultura aberta da Califórnia, a relação de apoio da Stanford University com o setor, a profusão das invenções da Fairchild Semiconductor, uma política de imigração liberal para alunos de doutorado e também ... pura sorte, entre outras coisas. O Vale do Silício é, além disso, alimentado por uma superabundância de conhecimento tecnológico e técnico. Desenvolver uma “indústria baseada no conhecimento” é uma meta admirável, mas para atingi-la é preciso um investimento maciço em educação durante toda uma geração, bem como a capacidade de desenvolver propriedade intelectual de primeira categoria. O local tem igual poder também de atrair empreendedores já feitos, que rumam para lá de todas as partes do mundo.

Deve-se casar o ecossistema às condições locais. Os líderes e pesquisadores públicos podem e devem promover soluções caseiras – baseadas na realidade de suas circunstâncias específicas (recursos naturais, localização geográfica, cultura). O governo deve envolver desde o começo a iniciativa privada. O poder público não pode criar um ecossistema sozinho. Somente o setor privado tem a motivação e a perspectiva para desenvolver um mercado com fins lucrativos que se auto-sustente. Deve ser priorizadas iniciativas de alto potencial. Muitos programas em economias emergentes distribuem recursos escassos por um sem-fim de empreendimentos na base da pirâmide. E, com efeito, alguns deles elevaram radicalmente a renda de certos segmentos da população. Mas concentrar os recursos ali em detrimento de empreendimentos de alto potencial é um erro gravíssimo na opinião do autor. Marque cedo um grande gol. Um sucesso visível logo cedo ajuda a reduzir a percepção de barreiras ao empreendedorismo e de riscos. Até um sucesso modesto pode ter um impacto.

"Um caso de sucesso, ainda que único, pode ter um incrível efeito estimulante sobre um ecossistema de empreendedorismo – ao despertar a imaginação do público e inspirar imitadores."
Daniel Isenberg, HBR 06/2010

Festeje abertamente os sucessos. O governo não deve medir esforços para celebrar empreendimentos que dão certo. Eventos de mídia, premiações altamente divulgadas, discursos e entrevistas do poder público exercem impacto. Encare o desafio da mudança cultural. Mudar uma cultura profundamente arraigada é extremamente difícil. A mídia pode exercer um papel importante na mudança de atitudes. Um exemplo: página semanal de histórias de sucesso de novas empresas. Seja exigente. É um erro encher o empreendedor, mesmo de alto potencial, de dinheiro fácil. Todo novo empreendimento deve ser exposto logo cedo aos rigores do mercado. Não planeje demais o cluster. Ajude-o a crescer organicamente. Popularizado por Michael Porter, a estratégia de cluster foi promovida mundialmente. Aqui no Brasil conhecemos como Polos de Tecnologia. Um governo deve fortalecer e explorar clusters existentes e em formação, e não tentar criar um inteiramente novo. Um cluster se forma quando o local apresenta uma base de vantagens. Reforme sistemas jurídicos, burocrático e regulatório. É necessário ter o sistema certo. Eliminar barreiras legais, de impostos e administrativas à formação de empresas é melhor do que criar incentivos para a superação dos obstáculos. Finalmente o autor sugere um questionário bem interessante para saber se os governos realmente possuem os elementos essenciais de um ecossistema empreendedor.

O Journal “Research-Technology Management” também traz algo sobre o assunto na sua edição de 12/2009. Um fator que determina uma competitividade de uma nação é o chamado “Innovation Ecosystem”, o qual inclui uma combinação de fatores relacionados com a criação de um ambiente amigável para a inovação (innovation friendliness) e também disponibilidade de capital de investimentos - ou capital empreendedor, na visão de Silvio Meira. A revista faz uma comparação interessante entre as competências dos CEOs do Hsinchu Science Park de Taiwan (400 empresas de tecnologias e responsáveis por 10% do PIB daquele país) e os CEOs do Vale do Silicio, mas as comparações param por aí. O governo reforçou vários elementos do ecossistema mais ou menos simultaneamente. Incentivou a pesquisa sobre o projeto e a produção de circuitos integrados, criou o Hsinchu Science Park perto de Taipei, passou a promover programas de capacitação na área de circuitos integrados, criou vínculos com empresários taiwaneses do setor de tecnologia radicados nos Estados Unidos e aprovou leis para incentivar o desenvolvimento de uma indústria de capital de risco local. Ainda na Research-Tecnology Management, em um artigo sobre “Outsourcing Innovation”, dois pesquisadores do INSEAD concluíram, a partir de um estudo, que dentro do conceito de Ecossistema de PD&I, existe cada vez mais atividades de inovação e serviços sendo realizados dentro do ecossistema, por qualquer ator envolvido e não apenas por um monopólio. Isto lembra a Hélice Tripla.

“O poder público precisa explorar toda experiência local disponível e se lançar a uma contínua experimentação. Por exemplo, mudar uma variável (ex. sistema jurídico/regulatório) de forma que constate se essas mudanças afetam uma ou mais variáveis (ex. maior participação da iniciativa privada).”

No Brasil, temos casos excelentes de ecossistemas, dentro de um perfeito conceito da Hélice Tripla, a exemplo de uma parceira recente entre a Natura (iniciativa privada), Embrapa Recursos Genéticos/Biotecnologia (governo) e a Funarbe da Universidade Federal de Viçosa (universidade). O projeto visa utilizar técnicas e processos inovadores no campo da genética voltada para a conservação, caracterização, valoração e uso de duas espécies de extrema importância para o agronegócio brasileiro: a erva-mate e a castanha do brasil. Quando Lula falou sobre criar uma Embrapa da indústria, concordo tecnicamente com ele. Porque não uma Embrapa da Tecnologia da Informação ou uma Embrapa da Saúde também?. O trabalho fundamental da Embrapa em inovação na agricultura é bem conhecido. Muitos resultados de PD&I possuem a característica de serem bens públicos, com benefícios sociais superiores aos privados. A falta de apropriabilidade dos retornos aos investimentos torna a pesquisa não atrativa para as empresas privadas. Existe também a incerteza na obtenção de resultados. Empresas privadas, aversas ao risco, pela própria natureza de sobrevivência, tendem a aplicar menos recursos em pesquisa do que o recomendado para se obter o máximo de bem-estar para toda a sociedade. Se existem retornos crescentes à escala, pode-se esperar a existência de algum tipo de monopólio nesse mercado. Pequenos empresários dispersos demandam tecnologias, mas não têm capacidade, nem financeira nem organizacional, para assumirem tamanho risco na geração delas. Grandes empresas que realizam pesquisas têm mais chances de distribuírem os custos fixos, de uma dada inovação, sobre mais unidades de produto do que uma firma pequena. Nesse aspecto a pesquisa e a transferência de tecnologia para a iniciativa privada é uma alternativa de ecossistema que pode ser explorada de forma maior pelo governo brasileiro, buscando também formas de remuneração sem onerar o empreendedor.

Para promover as mudanças fundamentais em meio a tantas incertezas, é preciso que o governo brasileiro, em parceria com institutos de pesquisas, iniciativa privada e com universidades experimente e aprenda em caráter permanente. As iniciativas não podem ser desperdiçadas na busca de uma meta impossível de um ecossistema (ex. criar outro Vale do Silício). Soluções caseiras podem e devem ser promovidas. A Embrapa é um exemplo.

A Importância da Função Catalisadora no Processo de Inovação

2010-05-29T11:25:00.000-07:00

A Química nos ensina que um catalisador é toda e qualquer substância que acelera uma reação, diminuindo a energia de ativação, diminuindo a energia do complexo ativado, sem ser consumido. A catálise é a mudança de velocidade de uma reação química devido à adição de uma substância (catalisador).

“Os catalisadores agem provocando um novo caminho reacional, no qual tem uma menor energia de ativação”

No processo de inovação, podemos fazer uma correlação com a função de catálise. O aumento da velocidade é explicado pelo fato de o catalisador (time de inovação) gerar um caminho alternativo (processo de inovação) para que a reação (produto ou serviço inovador) ocorra com menor consumo de energia (investimento necessário na idéia e no projeto, alcançando um ROI mais rápido). A energia de ativação (força necessária para que a idéia se converta em um projeto de inovação) é um obstáculo para a ocorrência da reação. Na ausência de forças, o que está em repouso continua em repouso (uma parte da Lei da Inércia). A aplicação de um catalisador (força) torna a ativação do processo de inovação mais ágil e fácil.

"A essência da verdadeira inovação é a ... FORÇA. A fonte número 1 de inovação são pessoas P... da Vida."

Tom Peters, Reimagine

Nesse contexto, uma função de catalisação da inovação deve ser responsável por todo o processo e deve ter autoridade organizacional. Além disso, deve apoiar os gestores de linha na avaliação da viabilidade do projeto. Um time de inovação deve atuar como um catalisador, iniciando-se por uma completa avaliação do estado atual da inovação dentro do negócio, incluindo o grau de socialização, externalização, internalização e combinação do conhecimento (Takeuchi e Nonaka). Com base nessa avaliação, pode-se chegar a conclusões de que, por exemplo, existe um monte de idéias, mas falta a execução disciplinada para alcançar o retorno desejado pelo negócio.

No livro “Payback, A Recompensa Financeira da Inovação”, Andrew e Sirkin sugerem que os candidatos que atuarão como catalisadores devem possuir certas características, dentre elas uma sólida reputação na empresa, suficiente relacionamento interdepartamental e hierárquico para ter autoridade de indicar e executar mudanças, uma plena compreensão do negócio e experiência com os produtos e funções empresariais, uma atitude colaborativa, capacidade de facilitar as coisas, além de um forte senso de urgência e disciplina. Acrescentaria a esta lista uma boa visão de finanças corporativas para atividades de acompanhamento da curva financeira da inovação, análise de ROI, relatórios dos investimentos, busca de financiamento etc. Por que não os profissionais catalisadores também possuírem uma boa dose de criatividade para auxiliar os inovadores ? Conforme Steve Jobs, criatividade é conectar conhecimentos e experiências e criar coisas novas. Tem tudo a ver !!!

Na edição de 02/2010 da HSM Management, a professora Jeanne Liedtka, da Darden Business School da Universidade de Michigan, em seu artigo “6 Rotas de Líderes Catalisadores” resume bem o que se entende como Catalisadores de Inovação. “Tente colocar um fósforo aceso sobre um monte de açúcar. Nada acontecerá, porque, para colocar fogo no açúcar, é preciso mais calor do que um único fósforo pode fornecer. O monte de açúcar permanece, não importando quantos fósforos você jogue sobre ele. Mas coloque apenas um pouquinho de cinza de cigarro no topo do açúcar e veja o que acontece quando você risca o fósforo: um inferno surge sobre a mesa, só por causa de um pouquinho de cinza. A cinza é um catalisador. Na química, o termo se refere especificamente a um agente requerido para que uma reação química seja ativada. Em outras palavras, catalisadores não apenas fazem as coisas acontecer – eles fazem coisas que não aconteceriam sem que eles estivessem presentes. Eles conseguem isso ao reduzir as barreiras que, em circunstâncias normais, impediriam a reação.”

Imagino que em várias empresas o açúcar já está sobre a mesa, talvez com uma tonelada de fósforos desperdiçados. Apresentei aqui algumas idéias para apoiar a catalisação dessa reação. Eis um bom tema para debate ...

O que importa no atendimento de serviços de TI

2010-04-25T17:11:00.000-07:00

Um atendimento superior ao cliente é uma fonte essencial de vantagem para o provedor de TI. A revista Harvard Business de outubro/2009, em um artigo denominado “O que o cliente realmente quer do atendimento” afirma que o cliente atual não tolera mais o atendimento típico. O que quer, hoje, é uma experiência que satisfaça. O provedor que atender a esse desejo terá sua lealdade.

Em uma pesquisa realizada pela Convergys em 2008, constatou-se que ao ligar para atendimento de um service desk, o cliente fica atento sobretudo a duas coisas: se o funcionário do outro lado domina o assunto e se o problema é resolvido no primeiro contato. Muitas vezes, no entanto, esses fatores nem sequer estão no radar de gerentes de service desk. O provedor segue monitorando o tempo de espera e a duração da chamada – como faz há décadas.

Mas existem armadilhas na busca da melhoria do tempo médio de atendimento (atenção maior ao cliente) e aumento de suporte no 1º. contato. Existe um perfeito trade-off entre estes dois indicadores e o abandono das ligações. Na minha tese de doutorado, defendida recentemente, desenvolvi um método quantitativo para avaliar a correlação entre os diversos indicadores de atendimento e a tomada de ações para um equilíbrio que pudesse satisfazer os clientes. Por exemplo, um foco excessivo no Tempo Médio de Atendimento para aumentar o Suporte no 1º. Contato pode ser prejudicial para a satisfação do cliente se não for estabelecido um limite tal que não impacte a taxa de abandono ou o tempo médio de espera.

Ainda de acordo com a Harvard Business, ao avaliar o atendimento, é preciso computar, em todos os canais, a parcela de problemas resolvidos já no primeiro contato feito pelo cliente, determinar qual a causa de problemas que não são solucionados de cara e fazer mudanças necessárias. Outra meta é garantir que toda interação entre clientes e atendentes seja de alta qualidade.

“O bom atendimento responde a perguntas sem deixar o cliente esperando na linha, sem buscar ajuda ou sem transferir para outra pessoa”

Como já mencionado anteriormente neste blog, No livro “O Futuro da Competição”, o saudoso Professor e Guru C. K. Prahalad (falecido em 2010) manifesta sua irritação pelo fato dos atendentes de service desk serem geralmente avaliados em termos de produtividade e metas estipuladas em processos, em vez do valor e do retorno do atendimento para o cliente.

Na famosa equação de Lead Time aplicada em serviços, a equipe de suporte deveria estar sempre atenta ao indicador resultante do backlog de chamados (work in process) dividido pela capacidade/dia de atendimento (exit rate). Se este indicador for maior que o maior nível de serviço estipulado com o cliente (SLA), pode ficar preocupado. As causas devem ser avaliadas imediatamente. Uma ação recomendada é trabalhar influenciando as demandas dos clientes, para que não entrem no processo sem motivo justificado. Treinamentos de clientes, uso intensivo de tecnologia, adoção eficaz de base de conhecimento, capacidade de transferência de conhecimento dos atendentes para os clientes e outros mecanismos sempre serão mais econômicos do que aumentar o contingente de profissionais ou pressionar no aumento de produtividade (existem limites). Para quem estiver interessado no assunto Lean Six Sigma aplicado em Serviço de TI, recomendo fortemente o livro “Lean Seis Sigma para Serviços” de um dos papas da área, Michael George.

Retomando o artigo da revista Harvard Business Review. Os autores Dougherty & Murthy observam que um atendimento ruim faz o cliente desaparecer sem o menor aviso. Cumprir apenas os indicadores de níveis de serviços (SLA) também é caminho para perder clientes. Há espaço para qualidade e inovação. Antes disso, porém, um bom atendimento no primeiro contato (porta de entrada do provedor de TI) já um bom caminho andado.

Governança e Serviços de TI na Segurança Pública

2010-01-31T11:43:00.000-08:00

Está disponível no site internacional do ISACA: http://www.isaca.org/ - Download - CobiT – Português a versão do CobiT 4.1 para a comunidade de língua portuguesa (Brasil, Portugal, Angola etc.). Sinto-me honrado de ter participado deste projeto, junto com algumas profissionais de SP, RS, RJ e BSB. Quem fizer o download vai reparar que na lista dos especialistas brasileiros que participaram da tradução e revisão consta um Coronel, um Tenente-Coronel e um Sargento da Polícia Militar de São Paulo. Interessante também que a PM de SP foi um dos primeiros cases mundiais de sucesso do ITIL v3 (versão completa). Segundo a Computerworld, existem 174 profissionais com a certificação ITIL na instituição. Outro detalhe, divulgado no site da FIAP (Faculdade de Informática e Adm. Paulista): o atual Comandante da PM-SP fez recentemente o MBA em Gestão de Tecnologia da Informação nesta Faculdade, onde fiz minha graduação em TI.

Em termos absolutos, São Paulo ainda é uma cidade violenta, porém, olhando de perto a Taxa de Homícidios por 100 mil habitantes (indicador mais utilizado mundialmente), este número está próximo do padrão da ONU que é de 10. Apenas para efeito de comparação, em capitais nordestinas como Salvador, Recife, Fortaleza e Maceió este indicador oscila acima de 60. A média brasileira é de 25. Sabemos que existem vários problemas na área de segurança pública no Brasil (ex. baixos salários do efetivo, corrupção, quantidade insuficiente de policiais e de espaços para detenções etc.). Em São Paulo, no entanto, a utilização das melhores práticas em Gestão de Serviços de TI, Controles e Governança parece estar ajudando a instituição na redução da criminalidade. Eis um bom exemplo para os demais Estados.

“Crimes são incidentes graves e uma gestão de problemas/mudanças eficaz ajuda em muito a redução ou eliminação destas ocorrências. Isto é ITIL !!”

Outro recurso importante de TI importante para a polícia é um banco de dados eficaz. Por exemplo, o CompStat (COMPuter STATistics) é um software da Polícia de Nova York e também uma grande arma contra o crime. Atualmente é replicado para outros Estados nos EUA. Utiliza técnicas estatísticas baseadas no Seis Sigma e no TQM (Total Quality Management) e recursos como Crime Mapping (GIS - Geographic Information Systems com recursos equivalentes ao Google Maps e ao Microsoft MapPoint) para identificar criminosos, rastrear suas ações, estabelecer perfis de vítimas potenciais, riscos, tendências etc. Mais informações sobre esta aplicação podem ser obtida no Wikipédia: http://en.wikipedia.org/wiki/CompStat.

Falando sobre o CompStat , em uma reportagem recente do Jornal Estado de São Paulo, Willian Bratton, ex-Chefe de Policia de Nova York e de Los Angeles, homem forte de Rudolf Giuliani entre 1994 e 2001, e estrategista do Tolerância Zero, relatou que os homicídios na Big Apple caíram cerca de 80% desde o início da operação, atingindo o menor nível desde 1964. Segundo o Policial, o CompStat permitiu identificar novos padrões de crime e atacá-los logo no início, deslocando homens e recursos de forma mais eficiente para cercar os criminosos. Em Nova York, o sistema era abastecido pelos 76 comandos das 9 áreas de policiamento e dos 12 distritos da região metropolitana. Além dos dados, os comandos tinham de apresentar um relatório sobre casos relevantes e uma análise dos crimes em sua área, as atividades e o desempenho de sua equipe. Tudo era discutido em encontros semanais com Bratton. O policial retrata um pouco desta experiência com o CompStat em Los Angeles em vídeo no youtube: http://www.youtube.com/watch?v=pltQi6aG4M8

Em São Paulo, a Polícia Civil utiliza o sistema Ômega, que permite pesquisar informações criminais em 12 bancos de dados. No entanto, a matéria do Estadão descreve dois problemas: a) integração com sistemas de outras polícias no País; b) Acesso da PF e da Abin aos dados. Apenas para citar mais um exemplo de uso de melhores práticas de Gestão de Serviços pela Segurança Pública: A Delegacia Seccional de Polícia de Avaré no interior de SP obteve recentemente a ISO 9001:2008, sendo a única Delegacia de Polícia Judiciária do Brasil com este selo. Segundo a reportagem, tem como principal objetivo a busca da melhoria contínua em relação aos serviços de segurança pública na cidade.

Eis alguns bons exemplos de uso de Serviços de TI na Segurança Pública que poderiam ser replicados para todo o Brasil.

Conceitos de Segurança e Auditoria de Software

2009-12-26T10:38:00.000-08:00

Ao realizar em 2009 os cursos de webcasting do ISACA (disponíveis em inglês em http://www.isaca.org/webcasts), algumas informações relacionadas à segurança no desenvolvimento de software me chamaram a atenção. Os cursos são de um nível excelente, propiciados pela maior autoridade mundial em Auditoria de Sistemas, Segurança da Informação e Governança de TI. Gostaria de compartilhar com os leitores do blog uma tendência cada vez mais quando o assunto é Segurança de TI: foco cada vez maior em Segurança de Aplicações (AppSec). Há algum tempo atrás a preocupação residia 100% nas estratégias de IAM (Identity and Access Management), SIM (Security Information Management) e TM (Threat Management), a exemplo de segurança física, redes, servidores, firewall, forensics, Single Sign-On, acesso, IDS, IPS, DNS, web server, browser e padrões como a ISO 27001 e Nist 800. Atualmente, a esta preocupação devem ser somadas as questões das vulnerabilidades internas dos bancos de dados, segurança do código de software desenvolvido, web application security e também novos padrões como OWASP, ISO 15408 e WASC. Percebe-se na figura abaixo que os ataques de sistemas na web estão ficando cada vez mais sofisticados e, se a aplicação não estiver preparada, o invasor consegue burlar a segurança e extrair dados confidenciais (senhas, contas, informações estratégias etc) da empresa por meio de código malicioso embutido em uma URL aceitável pelos mecanismos de proteção (firewall, DMZ, IDS etc.). Criptografia das requisições get e post, uso obrigatório de SSL, validação do lado do servidor são exemplos simples de boas práticas no desenvolvimento de aplicações que podem evitar este problema.

" Atualmente ameaças como SQL Injection, Flash Security, Clickjacking e outras devem estar na ordem do dia no desenvolvimento de software. "

Uma pesquisa realizada pelo ISACA detectou que 26% das páginas web estão em ASP, 22% em ASPx e 8% em JSP. A proporção não é a mesma em termos de vulnerabilidades detectadas: 25% para o código ASP, 9% para ASPx e 7% para JSP. As páginas desenvolvidas em ASP são antigas, utilizam na sua maioria o VBScript e o Javascript, sem maiores recursos de proteção avançada de segurança dos dados (ex. criptografia e proteção contra Injections Flaws). Outra questão fundamental abordada nos cursos é que o banco de dados é o repositório central de dados confidenciais e, como tal, deve ser altamente protegido. Pela pesquisa, 43% dos bancos de dados possuem dados confidenciais (como senhas, contas bancárias, código de cartões, informações pessoas etc.) e os ataques estão ficando cada vez mais sofisticados. Contas e senhas defaults, senhas de convidados (guess) de fácil acesso, ausências de patches, configurações fracas, privilégios excessivos de acesso. Detectar e eliminar estas vulnerabilidades deve ser uma preocupação constante do DBA (Administrador de Banco de Dados).

Melhores práticas de segurança em aplicações como o WASC e o OWASP já são utilizadas no mundo inteiro, mas não de forma suficiente. Há necessidade dos desenvolvedores de softwares serem cada vez mais capacitados nestas práticas. Na minha experiência acadêmica e também em empresas nacionais e multinacionais, detectei que os CSOs (Chief Security Officer) são, na sua maioria, originários da área de infraestrutura, o que dificulta a comunicação destes profissionais com a área de aplicações de uma forma plena. Estes profissionais têm um desafio agora de entender um pouco mais de desenvolvimento de software e dos diversos mecanismos de proteção que o desenvolvedor pode e deve utilizar para entregar um software seguro ao cliente.

Em resumo, o OWASP (http://www.wasp.org/) reúne recomendações para os chamados Top 10 de ameaças em segurança de aplicações na web, sendo elas: XSS, Injection Flaws (SQL, XML, LDAP etc.), Malicious File Execution, Insecure Direct Object Reference, Cross Site Request Forgery (CSRF), Information Leakage and Improper Error, Broken Authentication and Session Management, Insecure Cryptographic Storage, Insecure Communications e o Failure to Restrict URL Access. Também aborda o SAAM (Software Assurance Maturity Model), estruturado em quatro níveis de maturidade de segurança em aplicações. Finalmente, apresenta as melhores práticas em testes de segurança de software em todas as etapas do ciclo de vida do desenvolvimento. A propósito, foi realizado no Brasil em novembro (Brasilia) o primeiro congresso AppSec do capítulo Brasil do OWASP. Os slides do evento podem ser encontrados aqui: http://www.owasp.org/index.php/AppSec_Brasil_2009_(pt-br.

Quanto à Auditoria de Software, esta deve ser realizada em todas as etapas do ciclo de vida de desenvolvimento (SLDC) e também em qualquer forma de desenvolvimento (Agile, OOPS, Incremental, Prototipação, Cascata etc.). Listas de verificações são ferramentas altamente importantes para uma boa auditoria, além do uso das melhores práticas de Auditoria de Processos e de Systems Audit (CISA, SAAM, Cobit Assurance Guide, ISO 19011 e outras). Recomendo fortemente o livro “The Software Audit Guide” da ASQ – American Society for Quality (vide figura neste post). Bem, este foi apenas um briefing deste assunto tão complexo que é a AppSec. Espero ter apresentado alguns conceitos úteis para desenvolvimento de uma aplicação segura e confiável. Eis um bom assunto para realização de pesquisas pelos estudantes de computação e sistemas de informações interessados em Segurança da Informação e Auditoria de Sistemas e também para os CSOs.

Resolução de Problemas em Serviços de TI

2009-11-21T06:02:00.000-08:00

Passei a gostar de Filosofia e sua utilidade nas minhas aulas do Doutorado. Em uma matéria de Ética e Gestão Ambiental tive contato com os ensinamentos sobre Método de René Descartes, Ética de Kant/Hegel e Tédio/Stress de Schopenhauer. Em seu famoso livro “Discurso do Método” de 1632, Descartes dizia que a filosofia era uma coleção de opiniões e, para não basear decisões em opiniões, resolveu sair do conforto do seu quarto aquecido e caminhar pela fria Europa para conhecer a verdade. Neste livro (encontrado em qualquer livraria. Comprei o meu por R$ 10,00), ele recomenda, entre outras coisas:

“Nunca confiar nos sentidos, em vez disto procurar todas as evidências possíveis sobre a veracidade de qualquer coisa.”

Dividir cada um dos problemas em tantas parcelas quantas forem necessárias (mais tratáveis). Começar pelos objetos mais simples e mais fáceis de serem conhecidos para, aos poucos, como que por degraus, chegar aos mais complexos e, para cada caso, fazer enumerações o mais exatas possíveis a ponto de estar certo de nada ter omitido. Eis alguns trechos do livro.

No Brasil, entre os seguidores do método de Descartes temos o INDG (Vicente Falconi), Ambev e Gerdau. O professor Falconi, em entrevista a HSM Management em 2008, falava que o método é a busca e o conhecimento da verdade (do grego Meta = Meta, Hodos = Caminho, portanto: Caminho para a Meta). Existem as verdades mostradas na análise dos dados e fatos. E as empresas, na grande maioria, não trabalham com elas. As pessoas vivem tomando decisões, que custam milhões, baseadas em opiniões. Todo gestor deveria ler Descartes. Precisa ser normal um bom gestor exigir que um plano de ação se baseie em análise, em qualquer nível hierárquico. As pessoas têm de achar, naturalmente, que é a análise que funciona. Vicente Falconi conta um fato curioso que aconteceu na Ambev. Numa reunião, quando o sujeito chegava lá com um plano de ação, o Carlos Brito (Presidente Mundial da InBev) pedia para ele mostrar a análise. Não tendo análise, o Brito dizia: “Não acredito nas ações que você propõe”. O Brito começou a fazer isso sistematicamente e dali a pouco todos faziam análise.

Traduzindo o método de Descartes para o mundo da informática. Na Gestão de Serviços de TI, os problemas não são vistos como oportunidades de melhoria, mas sim de fracassos e, desse modo, são ocultados em vez de serem abordados. Existe uma tentação de passar do problema direto para um plano de ação, sem uma análise bem elaborada. Existe a necessidade de reforçar que a identificação correta do problema é a fase mais importante e deve ser a etapa onde a maior parte do esforço é aplicada, já que um excelente trabalho para resolver o problema errado tem pouco impacto a longo prazo.

“Não se deve resolver um problema de 5 centavos
com uma solução de 1 real.”

Bem, quais as alternativas ? Existem vários métodos de resolução de problemas indicados para serviços de TI. Vou abordar aqui algumas visões incorporadas em três conjunto de melhores práticas: ITIL v3, CMMI 1.2 for Services e STP (Sistema Toyota de Produção). Bem, o ITIL v3 tornou-se muito mais prescritivo no processo de gerenciamento de problemas, trazendo conceitos como gráfico de ishikawa, 5 whys e outros. No ITIL v2 a análise de causa raiz (RCA) resumia-se à descrição do seu conceito. O ITIL v3, Além do KEDB (Known Error DataBase) que faz parte do SKMS (Service Knowledge Management System), traz uma série de ferramentas úteis para análise. No apêndice D do livro Service Operation, é apresentado o diagrama de ishikawa com uma série de passos para análise da causa raiz. No apêndice C é apresentado o método Kepner & Tregoe para análise de resolução de problemas. Este conceito trabalha com a definição do problema, estratificação, estabelecimento das possíveis causas (utilizando técnicas como 5whys), teste da causa mais provável e elaboração do plano de ação para resolução da causa raiz. O CMMI 1.2 for Services apresenta dentro da área de processo CAR (Causal Analysis and Resolution) uma série de sub-processos direcionados para análise e resolução de problemas. Contempla seleção de defeitos e problemas, análise de causas, Implementação das ações, análise da eficácia e registro em base de conhecimento. O CMMI recomenda também técnicas prescritivas com o Pareto, 5Whys, Ishikawa, 5w2H (plano de ação) e DOE (Planejamento de Experimentos). Traz também em suas práticas genéricas provisão de recursos, determinação de responsabilidades e envolvimento de stakeholders no processo de CAR. O SD (Service Delivery), um dos novos processos do CMMI Svc, aborda vários assuntos relacionados com o tema, a exemplo de análise de performance de dados e prevenção de incidentes em aplicações.

No STP (Sistema Toyota de Produção), a metodologia de solução de problemas percorre toda a empresa e todas as funções. A melhoria deve ocorrer em todo o tempo, em todos os níveis e em todos os profissionais. Lembro-me de um caso contado no livro de Michael Hammer, “a Agenda”, sobre um faxineiro com visão de processos e outro sem nenhuma visão. Ao perceber a presença de um chiclete no chão, o primeiro passa a vassoura e não o remove (sua visão é de passar a vassoura de um lado para o outro) enquanto o segundo preocupa-se em pegar uma ferramenta para retirar o chiclete. Sua preocupação é ter a sala limpa, pois alguém precisará dela na sequência (reunião, treinamento). Este segundo profissional vai além: sugere uma conscientização para os usuários da sala não jogarem chiclete no chão (resolução do problema). Na Toyota é sempre questionado: “por que você escolheu este problema ? “, “Como você determinou que o problema merece seu tempo e atenção ?. O STP questiona a tendência de “pular” imediatamente do “problema” para a “solução”, exatamente como afirmava Descartes. Com relação a análise de causa raiz o STP enfatiza bastante o conceito de 5whys (cinco porquês). Segundo o método, em quase todas as situações, há várias causas para os problemas; assim, a análise deve ser abrangente.

“Como há diversas causas possíveis, é necessário limitar-se às mais significativas. A limitação permite a concentração dos esforços para gerar melhores resultados.”

Pelo que foi explicado, conclui-se que há necessidade das empresas e departamentos de TI ensinarem habilidades básicas de solução de problemas para todos os seus profissionais, de modo que todos se tornam solucionadores de problemas, com claro retorno de investimento. Não ficaremos mais no “apagar incêndio” do dia-a-dia. Uma frase do STP que carrego sempre comigo é: "A Densidade gera mudanças". Para um conhecimento mais avançado dos métodos apresentados, recomendo a leitura de dois livros: Root Cause Analysis (RCA) da ASQ (American Society for Quality) e do livro Root Cause Analysis Handbook (vide fotos neste post). Bem, eis um assunto bem instigante e desafiador.

De onde vem os inovadores? (Parte 2)

2009-10-03T14:46:00.000-07:00

Onde estão os inovadores? Como localizá-los?. Esta segunda parte do post tenta fornecer mais subsídios para este grande desafio. Bem, Napoleão identificava os seus futuros comandantes já no inicio da carreira militar. Dava a estes acesso a recursos, autoridade e oportunidade para que provassem seu valor. Prahalad & Hamel, na consagrada obra “Competindo pelo Futuro”, abordaram o conceito de “Ativistas Revolucionários”. Uma empresa repleta de clones altamente socializados, com pensamentos semelhantes, provavelmente não criará o futuro; por outro lado, uma empresa repleta de renegados interessados apenas em si mesmos, também não criará o futuro. Segundo eles, os ativistas são profissionais que não tem medo de desafiar o status quo, não tem medo de dizer o que pensam, mas que também tem uma profunda visão estratégica e o desejo de melhorar não apenas o seu destino pessoal, mas também o dos outros. Estes são os inovadores. É preciso ir atrás deles.

“ Em empresas de sucesso, um individuo desse tipo deve ser incentivado a trabalhar com altos executivos em postos de linha cruciais para identificar inovações que possam mexer com a organização inteira. “

A revista Harvard Business Review de dezembro/2008 publicou uma matéria interessante sobre o tema “de onde vem os inovadores”. Sob o título “Como achar e preparar inovadores revolucionários”, o artigo aborda que empresas de destaque contam com processos internos de gestão de talentos e colocam seus inovadores na linha de fogo, onde prospera quem é inovador por natureza. Mentores e redes de conhecimentos são um apoio crucial. Depois de preparado e instalado no meio da organização, onde vira um “Centro de Inovação”, o inovador em ascensão consegue enxergar melhor como recombinar produtos, idéias e pessoas da organização – ou até de negócios inteiros – agregando valor no processo.

Ainda segundo a revista, um inovador fecha o foco nos aspectos mais importantes e não perde tempo com questões periféricas. Isso é importante, considerando a incrível quantidade de dados, idéias e, não raro, preferências conflitantes de clientes com que ele precisa lidar. É alguém com capacidade de encaixar as peças em um todo integrado e que também pensa de modo estratégico. Uma desconfiança básica leva essa pessoa a não contar com algo que já deu certo e a avaliar cada novo desafio do zero.

“ O inovador é alguém capaz de formular e reformular o desafio de pontos de vista distintos e identificar que soluções teriam mais chances junto a gente influente em sua organização.”

O interessante desta abordagem da Harvard Business, é que contraria o que presenciamos no dia-a-dia das empresas. Os gerentes ficam confiantes demais depois de uma série de triunfos (ex. execução de um projeto de TI com sucesso) e começam a acreditar em sua própria avaliação de desempenho, em conversa de corredores e em outros indicadores – e hesitam em reinventar a roda se uma certa abordagem funcionou tão bem no passado. Bem, três aspectos são apontados pela revista como maior desafio na identificação e preparação de uma geração de inovadores revolucionários. Uma empresa de sucesso:

Vasculha a casa atrás de talentos brutos – Busca, entre gente de alto potencial, aqueles que nunca estão satisfeitos em seguir as melhores práticas de ontem e que exibem habilidades incomuns.
Testa esses talentos com munição viva – Dá aos inovadores projetos de verdade e acesso à alta gerência.
Destaca mentores e incentiva redes de pares – Um mentor supre o inovador em ascensão de informações sobre pessoas com quem provavelmente travará contato e interações que provavelmente terá. O inovador é incentivado a buscar feedback em grupos de colegas na mesma situação.
Administra ativamente a carreira do inovador – Busca instalar o inovador fora da estrutura regular, aumentando assim a probabilidade de que venha a criar negócios totalmente novos.

Bem, a busca de inovadores em tecnologia da informação não é diferente. Empresas de TI que cultivam gente inovadora terá mais condições do que as concorrentes de se ajustar às mudanças de mercado e aos diversos cenários tecnológicos e econômicos. Eis um excelente tema para debate.

De onde vem os inovadores? (Parte 1)

2009-08-23T08:43:00.000-07:00

Gary Hamel, famoso guru de estratégia e inovação, descreveu em uma das suas obras que a inovação radical na nossa área de tecnologia da informação, como em outras áreas de conhecimento, obedece à lei da potência. Para cada mil idéias bizarras, apenas cem merecerão ser experimentadas; dessas, não mais de dez acabarão produzindo um investimento substancial , e somente duas ou três acabarão produzindo um investimento de alta rentabilidade. Mas, como produzir estas idéias. Bem, na maior parte das organizações, os futuros inovadores estão ocultos da diretoria, embrenhados em vários cargos de linha. É preciso ir atrás deles e, pelo menos temporariamente, retirá-los de suas atividades cotidianas. Este post e o próximo visam fornecer uma contribuição neste sentido.

“... a fonte de inovação no. 1 é feita de pessoas irritadas – pessoas que não conseguem lidar com ineficiências e tolices que vêem ao seu redor.”
Tom Peters

De onde vem os inovadores ? Quais são suas características ? Segundo a Harvard Business Review, uma coisa é certa: para ter idéias originais, um potencial inovador deve passar por duros testes e ser instalado no posto certo na empresa. Hamel já falava que não basta ter uma ideologia, é preciso ser capaz de transmití-la, de contagiar os outros com suas idéias. Segundo ele, os ativistas são patriotas voltados para a proteção da empresa contra a mediocridade, a estreiteza dos interesses pessoais e a adoração do passado. Sua meta é instigar movimentos dentro da empresa e deflagrar a revolução fora dela. Nesta primeira parte do post, gostaria de compartilhar com vocês as lições de um inovador que reflete bem este tipo de profissional: Steve Jobs da Apple.

Jobs é o grupo de foco de um só homem da Apple. Jobs não tem formação técnica em engenharia ou computação. Não tem um MBA. Na verdade, não é formado em coisa alguma, pois abandonou a faculdade. Jobs não pensa como um engenheiro, mas sim como um leigo, o que faz dele a mais perfeita bancada de testes para os produtos da Apple. Ele não teve treinamento formal, mas trabalha com tecnologia desde a adolescência. Tem conhecimentos técnicos suficientes e o ponto de vista de um leigo. É uma grande vantagem. Jobs é um elitista que acredita que uma pequena equipe nota 10 é muito mais eficiente do que exércitos de engenheiros e analistas. Ele sempre buscou a mais alta qualidade em pessoas, produtos e publicidade. A estratégia dele é contratar os mais inteligentes analistas, engenheiros e designers. Na visão de Jobs, não há muita diferença entre um motorista de táxi bom ou ruim, ou entre cozinheiro de restaurante bom ou ruim. Um bom motorista de táxi talvez seja duas ou três vezes melhor que um ruim. Não há tantos níveis de habilidades. Mas, quando se trata de desenvolvimento de sistemas ou de designers, há uma vasta diferença entre os dois extremos. Um bom designer é cem ou duzentas vezes melhor do que um que seja fraco. Em desenvolvimento de sistemas, há muitos e muitos níveis de habilidade separando os grandes programadores e analistas de sistemas dos medíocres. Jobs adora o trabalho intelectual. Ele quer uma discussão de alto nível – uma briga, que seja – porque é a maneira mais eficaz de chegar ao fundo de um problema. Ele força as pessoas a defenderem suas posições.

Jobs geralmente presta muita atenção à experiência do usuário. Jobs não acredita na sistematização da inovação. Seus heróis em inovação são personagens históricas no mundo dos negócios como Henry Ford e Thomas Edison. Na história dos negócios, as companhias mais bem-sucedidas não são as inovadoras de produtos, sim as que desenvolvem modelos de negócios inovadores. Os inovadores de gestão pegam as invenções dos outros e as aprimoram, descobrindo novas maneiras de fabricá-las, distribuí-las ou comercializá-las. Henry Ford não inventou o automóvel, mas aperfeiçoou a produção em massa. A Dell não desenvolveu novos tipos de computadores, mas criou um eficiente sistema de distribuição direta ao consumidor. A Apple procura fazer as duas coisas: inovação em produto e inovação de gestão. Jobs desenvolveu diversos modelos de negócios inovadores. De onde vem a inovação ? na visão de Jobs, a inovação vem de pessoas encontrando-se nos corredores ou telefonando umas para as outras às 22:30h com uma nova idéia, ou porque perceberam algo que evidencia as falhas em nossa forma de pensar um problema. Vem de reuniões improvisadas de seis pessoas convocadas por alguém que descobriu algo novo ou sensacional e que saber o que os outros acham da sua idéia.

" Grande parte da inovação na Apple diz respeito a moldar a tecnologia de acordo com as necessidades do consumidor, sem tentar forçar o usuário a adaptar-se à tecnologia. "

Mesmo tendo reputação de chefe cruel, Jobs é apaixonado pelo que faz e inspira os subordinados. Quando ele pendurar as chuteiras, talvez a empresa perca o charme. E algumas pessoas podem perder o desejo de trabalhar na Applle caso o ícone do mundo da computação não esteja por perto. Jobs concebe todos os produtos com base num projeto que seja atraente para o consumidor. A partir daí, é dever dos engenheiros encaixar todos os componentes no design proposto. Para Jobs, inovação tem a ver com criatividade, com juntar as coisas de formas únicas. Criatividade é apenas conectar as coisas. Quando você pergunta a pessoas criativas como fizeram alguma coisa, elas se sentem um pouco culpadas, porque, na verdade, não fizeram aquilo; elas só viram aquilo. A coisa lhes pareceu tão óbvia, depois de certo tempo, porque conseguiram conectar experiências que tiveram e sintetizar coisas novas. E o motivo pelo qual elas conseguiram fazer aquilo é que tiveram mais experiência ou pensaram mais sobre suas experiências do que outras pessoas ... Infelizmente, diz ele, isso é uma coisa muito rara. Muitas pessoas em tecnologia da informação, por exemplo, não tiveram experiências muito diversificadas. Então, não tem pontos suficientes para juntar e acabam tendo soluções muito lineares sem uma perspectiva mais ampla do problema.

A minha experiência trabalhando com tecnologia da informação em empresas nacionais e multinacionais no Brasil às vezes comprovam a visão aqui apresentada. As organizações formam líderes que, em vez de inovar, repetem o que já se faz. Um inovador em potencial percebe que, para ser promovido, precisa espelhar os líderes atuais. Bem, vou falar mais sobre isto na sequência deste post.

O Uso das Práticas de Gestão de TI por toda a Organização

2009-08-08T07:21:00.000-07:00

A TI tem utilizado vários conceitos originados de outras áreas de conhecimentos, a exemplo da Qualidade Total, que inspirou o uso de técnicas como Lean Six Sigma em CMMI ou Sistema de Gestão da Qualidade em Serviços de TI, como o utilizada na ISO 20000. Também utiliza-se da Gestão de Projetos, prática criada inicialmente para grandes projetos de engenharia na década de 50/60. Algumas práticas de TI como Gerenciamento de Capacidade, Continuidade, Configurações e Mudanças do ITIL não são reinvenção da roda. Todas foram inspiradas em conceitos de gestão das décadas de 60/70. A Gestão de Problemas foi outra técnica do ITIL, inspirada nos princípios de resolução de problemas baseados no Sistema Toyota de Produção. Outro exemplo bem característico é a Fábrica de Software, inspirada nos conceitos tradicionais das linhas de fabricação das indústrias. Em IT Services existe uma grande preocupação com o Lead Time de chamados em Service Desk e Field Support, inspirado nos conceitos de Lean Manufacturing (Produção Enxuta), onde os inputs são os incidentes e solicitações registradas, o WIP (Work In Process) é o backlog de chamados e o Exit Rate a quantidade média dos chamados resolvidos pelos analistas.

Bem, e quanto à contribuição de práticas de TI para outras áreas corporativas e também da produção ? Em um artigo na MIT Sloan Management Review, mostrado na HSM Management de outubro/2008, Keith McFarland defende a idéia de que o modelo de planejamento estratégico parece estar pronto para uma “versão 2.0”, que permita às empresas manter-se atualizadas em ambientes de mudanças. Segundo o autor, desenvolvedores de softwares podem ajudar os estrategistas nisso. As técnicas ágeis de desenvolvimento de softwares (ex. Scrum) reconhecem que muitos programas podem ser desenvolvidos mais rapidamente e com maior sucesso quando no modo de repetição. Desenvolvedores percebem que não conseguem ter todo o conhecimento necessário para produzir o sistema perfeito. Assim, fazem com que modelos que funcionam cheguem às mãos dos usuários quanto antes. Eles podem, interagindo com esses usuários em um processo em espiral, integrar o feedback colhido às versões futuras. Como seria uma abordagem em espiral para a definição da estratégia? Ela reconheceria que estratégias podem ser criadas mais efetivamente quando a formulação e a implementação andam de mãos dadas. Admitiria também que, se as pessoas apenas focarem uma vez por ano aquilo que conduz os negócios, as idéias estratégicas evoluirão muito vagarosamente e não estarão em dia com as realidades dinâmicas do mercado (principalmente em tempos de crise financeira que estamos passando em 2009).

“Nós acreditamos que, quando o ritmo da mudança dentro de uma instituição se torna mais lento que o ritmo da mudança fora dela, o fim está próximo”.

Jack Welch

Costumo classificar o ITIL como um conjunto de melhores práticas de serviços e não apenas de TI. Desta forma, práticas como Gestão da Demanda, Gestão de Incidentes, Gestão de Catálogo de Serviços, Gestão de Problemas, Gestão de Capacidade, Gestão de Mudanças, Gestão de Liberação/Instalação, Gestão de Ativos/Configurações e Outras podem ser perfeitamente ajustadas para uso em outras áreas corporativas. Tive uma experiência há alguns anos atrás de implantar estas práticas, juntamente com uma ferramenta ITSM, em um área de Facilities, com total sucesso. Por que não utilizá-la também em RH, Compras, Produção e em outras áreas. Processos de Gestão de Demandas, Incidentes, Problemas, Mudanças etc. todas têm. Se bem ajustada à realidade de cada área, a implantação do ITIL ajudará a mapear e agilizar o fluxo de valor (uma das práticas da produção enxuta), separando atividades que agregam valor ao processo das que podem ser eliminadas, por serem desperdícios. Um exemplo disto é quando temos uma demanda do cliente para capacitação dos colaboradores de um projeto de TI (VOC – Voz do Cliente), poderíamos registrar um chamado no RH, seguindo todas as práticas de IT Service Management, como priorização, escalação, acompanhamento, satisfação etc. RH poderia depender de uma infraestrutura para os treinamentos. Registraria então um chamado em Facilities. Se ocorrer a necessidade de contratar o treinamento no mercado a área de compras será envolvida da mesma forma. Como se trata de uma única base de dados, tudo isto seria acompanhado pela empresa em termos de tempo, qualidade, desempenho etc., pois trataria de um processo que agregaria valor para o cliente. Trata-se de um exemplo muito simples das oportunidades que práticas como ITIL geram de benefícios na cadeia de valor da empresa.

O CMMI for Service 1.2. (complementar ao CMMI for Dev 1.2 e CMMI for Acq 1.2) ) importou várias práticas do ITIL v3 e da ISO 20000 dentro de seu modelo. Apesar de não ser tão prescritivo quanto o ITIL, este framework traz as vantagens de utilização dos processos de desenvolvimento de software (requisitos, treinamentos, controle e monitoramento quantitativo etc.), bem como aspectos vitais para qualquer serviço (Facilities, RH, Compras, Vendas etc.) a exemplo de gestão estratégica, capacidade, transição, entrega e continuidade do serviço. O CMMI-SVC, como também é conhecido, faz referência a serviços de sistemas e não apenas de aplicações. Entendendo sistemas de uma mais ampla, abrangendo itens de infraestrutura, instalações, aplicações, hardware, redes, pessoas etc, necessários para a prestação do serviço. A Governança de TI é outro conceito de TI que também tem inspirado o desenvolvimento de outros de tipos de governança em áreas corporativa, tanto que já se fala de Governança Corporativa de TI (IT Enterprise Governance) que já possui, inclusive, uma certificação específica, o CGEIT (assunto já discutido em post anterior sobre tendências de governança neste blog). Os Conceitos de Alinhamento da Área com o Negócio, Gestão de Riscos, Gestão de Performance, Entrega de Valor e outros temas não se referem apenas a TI, mas pode ser aplicado a qualquer outra área da empresa. A Governança Corporativa de TI está substituindo a Governança de TI. Isto significa que as informações, dados, sistemas e demais recursos não pertencem somente a área de TI, mas a toda a corporação. Já se fala também de Governança de RH, Governança de Compras e outras. Eis um belo exemplo da contribuição da TI para outras áreas corporativas.

Gestão do Conhecimento em Projetos de TI

2009-07-18T13:53:00.000-07:00

Os dados podem ser considerados como sendo uma seqüência de números e palavras, sob nenhum contexto específico. Quando os dados são organizados com a devida contextualização, há a informação. Já o conhecimento é a informação organizada, com o entendimento de seu significado. A Gestão de Conhecimento cuida de agregar valor às informações filtrando, resumindo e sintetizando estas, e dessa forma, desenvolvendo um perfil de utilização pessoal que ajuda a levá-las à ação e tomada de decisão. O conhecimento explícito, ou codificado, é o conhecimento cuja transmissão se dá através da linguagem formal e de forma sistemática. Pode ser armazenado e compartilhado, logo, mais fácil de gerenciar, podendo ser armazenado em normas, manuais e livros. O conhecimento não-explícito é igual ao conhecimento tácito. O conhecimento tácito é o conhecimento que a pessoa possui, incluindo suas habilidades. É pessoal, não pode ser expressado formalmente. É intrínseco à pessoa. Bem, Takeuchi e Nonaka (os autores mais conhecidos nesta área) já falavam que o conhecimento é criado através de interações entre os seres humanos e seu ambiente. Nossas ações e interações com o ambiente criam e ampliam o conhecimento, através do processo de conversão do conhecimento tácito e explícito. Ainda segundo os dois autores, existe quatro padrões básicos para a criação do conhecimento em qualquer organização: a) De tácito para tácito quando um individuo compartilha o conhecimento tácito diretamente com outro; b) De explícito para explícito, quando o indivíduo combina partes distintas do conhecimento explícito em um novo todo; c) De tácito para explícito com a articulação do conhecimento tácito e sua conversão em explícito e, finalmente, e) De explícito para tácito, quando à medida que o novo conhecimento explícito é compartilhado pela organização, outros empregados começam a internalizá-los.

Ainda sobre Gestão de Conhecimento, aconteceu neste mês de julho o V CNEG – Congresso Nacional de Excelência em Gestão na Escola de Engenharia da UFF - Universidade Federal Fluminense em Niterói-RJ. Estive presente apresentando um artigo sobre Gestão do Conhecimento em Serviços de TI, utilizando o modelo SKMS do ITIL v3. Trata-se de um modelo incorporado no processo de Gestão de Conhecimento na Transição de Serviços. Abrange o CMDB e CMS, bem como a aplicação das melhores práticas de gestão do conhecimento em serviços de TI. Bem, tivemos vários trabalhos interessante sobre Qualidade, Inovação, Conhecimento e Projetos. Os anais do congresso estão disponíveis em: http://www.vcneg.org/. Destaca-se um artigo sobre Gestão da Qualidade Total em Tecnologia da Informação de uma aluna de pós-graduação da UFF, Priscila Fraga. Mas, o que mais me chamou a atenção foi a grande quantidade de bons artigos relacionados com o tema Gestão do Conhecimento. Um assunto bastante comentado foi a Gestão de Conhecimento em Projetos. É um tema bastante atual e que é bastante citado no mercado. Neste mês de julho, foi publicado um artigo na revista Mundo PM sobre o tema, de autoria do Professor da FGV-SP, Paulo Sabbag. Também foi publicado um artigo no Project Management Journal do PMI, de autoria de professores da Simon Fraser University. Os autores citam os tipos mais comuns de conhecimentos em projetos de TI, sendo eles: a) Conhecimento do processo (estrutura do projeto, metodologias, atividades etc.); b) Conhecimento do domínio (conhecimento da indústria, cenários atuais, problemas, oportunidades e potenciais soluções); c) Conhecimento institucional (história da organização, estrutura de poder e valores) e, finalmente, d) Conhecimento cultural que abrange a necessidade de conhecimento que os gerentes de projeto precisam para liderar times de diferentes disciplinas e culturas.

No CNEG, tive um debate interessante com um doutor em Gestão de Conhecimento pela UNB. Ele apresentou um artigo sobre a gestão do conhecimento no Banco do Brasil, com destaque para a colaboração interna, visando ganhos de sinergia em projetos. É um assunto bem interessante. Sobre este aspecto, saiu uma matéria na Harvard Business Review de abril/2009 indicando benefícios potenciais da colaboração, como por exemplo: desenvolvimento transfuncional de produtos inovadores, maior faturamento graças à venda cruzada e transferência de melhores práticas para redução de custos. No entanto, existe um alerta. O artigo, assinado por Morten Hansen da Universidade de Berkeley e do INSEAD, sugere que a colaboração entre as unidades de negócios de um provedor de TI, por exemplo, não pode ser feita só pela colaboração em si. Existe um risco nesta atividade.

"A colaboração pode trazer enormes benefícios (produtos e serviços inovadores, novas receitas). Mas também pode trazer prejuízos se os custos (incluindo atrasos devido a brigas por território) foram maiores do que o esperado."

O certo seria perguntar se a colaboração em um projeto vai criar ou destruir valor. Colaborar bem é saber quando não colaborar. Um exemplo citado pelo autor foi em propostas de outsourcing de TI. Ele citou um estudo de caso: travando uma disputa acirrada com rivais como IBM e Accenture por contratos, equipes de pré-vendas volta e meia iam pedir conselho de equipes com experiências em, digamos, uma tecnologia que seria implementada no potencial cliente. Com o estudo, o autor chegou à conclusão de que quanto maior a colaboração (medida pelo total de horas de ajuda recebida por uma equipe), pior o resultado (medido pela conquista ou não do contrato). No final, houve a conclusão que uma equipe experiente em geral não aprende tanto com os colegas como achava que aprendia, não compensando o tempo que deixara de trabalhar na formulação da proposta. O problema era, antes, determinar quando colaborar fazia sentido. O autor também sugere três tipos de colaboração em época de crise: a) venda cruzada, criando programas para a venda de outros produtos à clientela atual; b) transferência de melhores práticas, identificando dentro da empresa, unidades eficientes em certas atividades e fazendo com que outras unidades sigam o exemplo; c) inovação de produtos transfuncionais, achando maneiras de combinar tecnologias, produtos e marcas existentes para criar novos produtos e serviços. Custa menos do que criar algo do zero e a chance de sucesso é maior.

A Qualidade como Oportunidade em Tempos de Crise

2009-06-30T16:39:00.000-07:00

A revista Quality Progress da ASQ – American Society for Quality (referência mundial em Qualidade Total) de junho publicou uma matéria interessante sobre como as empresas podem enfrentar a crise focando na qualidade dos seus produtos e serviços. Sabemos que a qualidade traz vantagens que podem ser traduzidas em termos financeiros para as empresas: aumento de produtividade, baixas variações percebidas pelos clientes, velocidade na produção e também redução de desperdícios. Porém, em tempos de recessão como a atual a qualidade geralmente é ignorada e seu orçamento é reduzido. Foca-se apenas na qualidade de conformidade, pois não tem jeito, como a manutenção das certificações ISO 9001, ISO 18000 e outras. O Departamento de Qualidade participa pouco nos processos produtivos, a satisfação dos clientes não é medida de forma proativa e utilizada para melhoria dos serviços, a alta direção não fornece os recursos e nem o apoio necessário para uma operação eficaz, os demais departamentos não têm certeza da função qualidade e o que ela representa, não existe interesse da empresa no treinamento em qualidade, a gerência de qualidade não tem acesso direto à alta direção da empresa, reduz-se o staff da área da qualidade e por aí vai... A revista aponta vários outros problemas.

A separação das atividades que agregam valor para o cliente das que não agregam, métricas de eficiência (Lead Time, Eficiência do Ciclo de Processo etc.), DMAIC, DFSS, MSA, QFD, Poka Yoke, Custo da Qualidade e outras técnicas ajudam em muito as empresas no sentido de enfrentar a crise atual. A revista também entrevistou alguns profissionais de mercado. Eles sugeriram investir fortemente no time em conceitos de qualidade, foco em resolução de problemas e maior controle das atividades para gerar redução de custos. Outros sugeriram focar em técnicas de melhoria contínua (ex. Kaizen, PDCA), melhoria radical (ex. Lean Six Sigma) e também em oferta consistente de serviços para seus clientes. Conquistar novos clientes é importante, porém, reter os atuais neste momento de crise é tão importante quanto.

“In hard times, if you are better than the
competition, they will get out and leave you
with a larger portion of the market.”
Quality Progress, June 2009

Em tempos dífíceis a qualidade pode ajudar as empresas a conquistar mercados. Bem, na minha visão a qualidade traz produtividade, redução da variação e de desperdícios, satisfação dos clientes e dos colaboradores e outros benefícios que se traduzem rapidamente em redução de custos e aumento das receitas. O resultado de tudo isto é lucro, rentabilidade e uma organização mais competitiva. Eis mais um excelente assunto para debate.

Tendências em Auditoria e Governança de TI

2009-06-13T06:04:00.001-07:00

Neste mês de junho, aconteceu em São Paulo o 6º. CONTECSI (Congresso Internacional de Gestão de Tecnologia e Sistemas de Informações) e o 18th WSAS (Simpósio Mundial de Auditoria Contínua) na Universidade de São Paulo. Participei apresentando um artigo científico sobre Auditoria em Serviços de TI. Foram apresentados trabalhos científicos de várias universidades e cases como o da IBM sobre um Modelo de Arquitetura para Auditoria Contínua. O evento contou com a presença de renomados professores da Universidade de New Jersey (Rutgers), Universidade de Paris, Universidade do Porto, Universidade Autônoma do México, Universidade Católica do Chile e outras. O evento foi patrocinado pela USP, Rutgers University e ISACA.

Algumas pesquisas interessantes foram apresentadas como a dos professores da Universidade Autônoma do México sobre um software de piscicultura e também um outro trabalho sobre implantação do ITIL do mestrado de computação da UFPE. Também tivemos vários artigos sobre Gestão de Mudança Organizacional em TI, ITIL/ISO 20000, Governança, Qualidade de TI, ERP, Tecnologia Móvel e Engenharia de Software apresentados por alunos a professores de pós-graduação da USP, UFRGS, UNICAMP, UFPE, UNB, PUC-PR, UFMG entre outras.

Bem, voltando ao assunto principal do congresso. O professor Miklos Vasarhelyi da Rutgers University e da PwC, maior autoridade mundial no assunto, define auditoria contínua como um tipo de auditoria que produz resultados simultaneamente ou em um pequeno período de tempo após a ocorrência de um evento relevante. Utiliza Uso intensivo de tecnologia para tratar grandes quantidades de dados e informações. Este uso intensivo da tecnologia explica-se pela necessidade da identificação e comunicação dos fatos relevantes em prazos muito curtos. Existe uma fronteira tênue entre auditoria contínua e monitoramento contínuo. A primeira avalia o controles e é realizada por uma equipe de auditoria. O monitoramento contínuo, por sua vez, trata da avaliação do processos operacionais e é executado pelo gestor. Também pode ser utilizada técnicas de “data mining” para detectar o que está “escondido” por trás das informações.

A auditoria contínua utiliza uma técnica denominada CAAT que significa “Computer Assisted Audit Tools and Techniques”, ou em uma tradução livre, Técnicas e Ferramentas de Auditoria executadas através de Computador. Inclui técnica como testes de dados e ITF (Integrated Test Facilicites). Os softwares mais utilizados para implementar o CAAT são o ACL e o IDEA. Recomendo o ACL pela facilidade de uso e pelo fato de ser uma referência na área. Existe versão para teste no site http://www.acl.com/. Na tela abaixo fiz uma pequena simulação com um dados do postgreSQL no software ACL para uma auditoria de dados.

A auditoria contínua pode ser utilizada por todas as áreas e não ficar restrita a um grupo ou a uma determinada área. Isto gera maior governança corporativa de TI. No ISACA Journal de junho saiu uma matéria interessante com o título “Moving From IT Governance to Enterprise Governance of IT”. Foi abordado que a Governança Corporativa de TI está substituindo a Governança de TI. Isto significa que as informações, dados, sistemas e demais recursos não pertencem somente a área de TI, mas a toda a corporação. O termo “TI” tem levado a debates da integração da área de TI com o negócio, quando o correto seria pensar na integração da TI corporativa, ou seja, de toda a organização. Desta forma, conceitos como auditoria contínua está relacionada à extração de informações e mineração de dados não mais por profissionais de TI, mas por um Contabilista ou por um Advogado, por exemplo. O ISACA criou a certificação CGEIT (Certified in the Governance of Enterprie IT) que está mais relacionada a este novo tipo de governança. Fui um dos primeiros a obter esta certificação no ISACA e hoje já são mais de 5.000 profissionais com este selo. Recomendo o livro “Enterprise Governance of IT” de Grembergen & Hae para maiores informações sobre o assunto. Os autores são da Universidade de Antuérpia, um dos centros de excelência nesta área.

Eis um campo bem interessante para o jovens que estão se formando em Computação ou Ciências Contábeis. Na minha opinião, o ideal é uma combinação das duas formações para um criar um diferencial nesta área. Um algo a mais seria a certificação CISA (Certified Information Systems Auditor) do ISACA, que fornece uma boa base para trabalhar com auditoria de sistemas, incluindo o uso das técnicas do CAAT.

A Oferta de Outsourcing de TI em Tempos de Crise

2009-05-30T05:48:00.000-07:00

Estamos em um momento difícil para quem vende para outras empresas. A oferta de serviços de software e de infraestrutura de TI também sofre este impacto. Afinal de contas, orçamentos de TI são um dos primeiros a serem cortados em situação de crise. Qualquer proposta de melhoria da TI está sujeita a um rigor maior na análise. O que fazer neste momento para manter ou até mesmo aumentar a venda de outsourcing ? Em um artigo da Harvard Business Review intitulado Value Innovation de 1997 e, mais tarde, revertido no livro Estratégia do Oceano Azul, Kim & Mauborgne relatam a necessidade da busca do aumento de valor oferecido aos clientes e baixos custos operacionais, simultaneamente. Em vez de concentrar-se em destruir a concorrência, o objetivo é torná-la irrelevante, oferecendo um salto de valor e criando uma nova demanda de Mercado. Esta frase é bem atual. Vejamos.

Adrian Slywotzky, Brilhante estrategista da Universidade de Harvard (recomendo ler o clássico Migração de Valor de 1996 dele, adotado na maioria dos MBAs), escreveu um excelente artigo na revista HSM Management no mês de abril/2009. Ele aborda um tema que passa despercebido por muitas empresas. As associações evocadas pela palavra “rentabilidade” são, frequentemente, numéricas: total de receitas, diferença em relação às despesas e balanço de resultados. Poucos a relacionariam com a arte. Em suas palavras: “A maioria das executivos percebe apenas uma maneira de gerar lucros, que costuma ser aquela com a qual está familiarizada ou a que leu no último número de alguma revista de negócios. Mas a realidade é muito mais complexa e promissora, ultrapassa o alcance de nossa limitada imaginação”. O panorama atual é complexo. Por isso, mais do que nunca, é hora de colocar em ação as melhores qualidades. Afinal, na intensidade dos momentos difíceis reluz o talento, tanto de líderes como de estrategista.

Para os provedores de TI, a informação detalhada sobre os clientes, coletada antes da recessão, é suficiente para entender a “economia” deles ou seria preciso buscar novos dados? Por exemplo, como o comportamento de compra se altera? É preciso ir além do conhecimento acumulado, por muitas razões, e Slywotzk destaca as duas mais importantes. Primeira: além de entender a cadeia interna de valor do cliente e a situação de seus resultados, é preciso também conhecer seu processo de tomada de decisão. E esse processo muda drasticamente em tempos de recessão: aumenta a orientação para o curto prazo e a preservação do caixa, e as prioridades econômicas do cliente se modificam. Não se pode confiar exclusivamente na informação recolhida sobre os clientes; é preciso calcular como seu processo de tomada de decisão e suas prioridades econômicas se modificam durante a recessão, quando os volumes caem. Os bancos, por exemplo, estão muito menos interessados em descobrir como ampliar o crédito a clientes marginais

Em artigo recente na Harvard Business Review, intitulado “Durante a crise, provoque seus clientes”, Lay, Hewlin e Moore da TCG Advisors relatam que não há como negar: é um momento difícil para quem vende para outras empresas. Simplesmente todas estão revendo investimentos e não há verba nos orçamentos.

Bem, o que fazer então para vender mais serviços de TI. Para garantir que o cliente libere recursos para uma venda de software ou de serviços de TI, formule um ponto de vista provocante sobre um problema crítico do cliente e apresente-o a um executivo de primeira linha. Para atingir o tomador de decisões no alto da empresa, abandone métodos tradicionais de prospecção e se concentre no marketing por indicação. Uma oferta de segurança da informação, por exemplo, pode sensibilizar mais os executivos preocupados com a proteção dos dados da organização. Outra dica interessante é identificar um processo crucial para o cliente no cenário econômico do momento e formular um argumento contundente sobre a falha desse processo e o que isso significa em termos de custo e, então, vincular o problema a uma solução que ele, o provedor, pode oferecer. Por exemplo, neste momento de crise a oferta de outsourcing que resolva algum problema na gestão de riscos pode alavancar oportunidades.

"O processo deve começar com um problema do cliente, e não com os recursos do produto ou do serviço de TI. "

O artigo da HBR defende o foco em uma ameaça séria no lucro do cliente, para que o executivo tenha motivos para receber o fornecedor – e para aumentar as chances de que seu investimento num processo de vendas mais oneroso seja adequadamente recompensando. Em tempos de crise, decisões de compra em tecnologia da informação não estará 100% com o CIO, mas com executivos com quem os provedores normalmente não lidam. Haverá necessidade de uma recomendação especial para ter acesso a esta gente. Bem, o objetivo dos provedores é estarem atentos às necessidades dos clientes dos seus clientes. Frases de campanhas publicitárias recentes no Brasil como : “inovar é fazer sua vida cada vez mais completa” ou “Inovação aberta com múltiplos atores no ambiente de trabalho”, podem indicar sinalizações da importância que alguns clientes dão para inovação & conhecimento. Empresas produtoras de commodities, cujo preços tem oscilado bastante no mercado mundial podem estar precisando de soluções de TI que os ajudem a gerenciar melhor sua gestão financeira e riscos.

“A equipe comercial do provedor poderia criar, para cada cliente atual ou potencial, uma longa lista de problemas do setor ou da empresa em questão – problemas que poderiam ser abordados de forma melhor. ”

Uma técnica que recomendo para detectar a lista de problemas (atributos de valor) atuais do cliente é a inovação de valor (estratégia do oceano azul). O segredo é detectar um problema com implicações tão profundas que mesmo durante uma crise o cliente achará dinheiro para resolvê-lo. Eis um bom tema para debate.

Aspectos Financeiros do Processo de Inovação em TI

2009-05-06T16:48:00.000-07:00

Na revista HSM Management de fevereiro/2009 saiu uma matéria de Silvio Meira sobre “Tudo que você queria saber sobre inovação e não tinha a quem perguntar”. Trata-se de uma visão da inovação por um inovador. Excelente reportagem. O que me chamou atenção é quando ele cita que no Brasil a visão de inovação é tão primária que, se você tiver uma padaria e comprar um novo forno, o banco de desenvolvimento que emprestou o dinheiro vai anunciar: “Estou financiando inovação”. Na realidade o que foi feito foi uma simples substituição para aumentar a eficiência. Segundo Meira, não se cria empresa inovadora de tecnologia com tecnologia, mas com dinheiro. A principal infraestrutura chama-se “capacidade inovadora do capital empreendedor”, inexistente no Brasil. Este capital faz mais do que colocar dinheiro. Ele detecta a oportunidade para a inovação e a põe no mercado. Ao ler os ensinamentos do mestre Silvio Meira, resolvi investigar um pouco sobre o assunto e compartilhar alguns conhecimentos complementares com os leitores do blog. Um briefing da matéria do Meira está disponível em: http://www.hsmmanagement.com.br/.

Bem, o economista Joseph Schumpeter definiu a inovação na década de 1930 como a obtenção de diferenciais competitivos pela modificação de produtos ou meios de produção. Ele classificou a inovação em três estágios: invenção, inovação e difusão. Enquanto a invenção é entendida como uma idéia potencialmente aberta para a exploração comercial, mas não necessariamente realizada, na idéia de inovação está implícita uma ênfase na exploração comercial. Por fim, a difusão está relacionada com a idéia de como novos produtos e processos se propagam pelos mercados potenciais. Outros autores modernos usam a mesma seqüência de fases com diferentes nomenclaturas e detalhes dos estágios. Bem, A inovação é um processo sistêmico, que envolve inúmeros atores que atuam segundo lógicas e prioridades distintas, e que só se realiza em um ambiente estimulante e catalisador de competências e iniciativas de cada um. De acordo com Tom Peters: “... a fonte no. 1 de inovação é feita de pessoas irritadas – pessoas que não conseguem lidar com ineficiências e tolices que vêem ao seu redor.”

“Pensar fora do normal: o alicerce do alto valor agregado”
Tom Peters, Reimagine

Gary Hamel, guru de estratégia e inovação, define bem o desafio da inovação para os profissionais que ele denomina de “ativistas”. Segundo ele, os ativistas são patriotas voltados para a proteção da empresa contra a mediocridade, a estreiteza dos interesses pessoais e a adoração do passado. Sua meta é instigar movimentos dentro da empresa e e deflagrar a revolução fora dela.

Veja diferente, seja diferente !!
Gary Hamel, Liderando a Revolução

Bem, estes são os conceitos mais comuns, mas, como podemos medir o retorno financeiro da inovação em TI. Em qual momento ocorre o ponto de equilíbrio em relação ao que foi gasto desde a concepção da idéia até o lançamento estabilização do produto ou serviço no mercado ?.

“Em uma manhã ensolarada na Califórnia, no final de agosto de 1998, Larry e Sergey, criadores do Google, sentaram-se na varanda de uma casa em Palo Alto, ansiosos pela chegada de Andy Bechtolsheim, investidor lendário de start-ups bem-sucedidas. Larry Page e Sergey Brin tinham uma grande idéia: eles haviam inventado uma maneira mais fácil de encontrar informação relevante em menos tempo na internet, o Google. Satisfeito com a demonstração, Bechtolsheim não perdeu tempo para fazer a pergunta mais importante. “Como vocês pretendem fazer dinheiro com isso? “. Ele disse. “Eu nunca me envolvo com idéias sem nenhum mérito econômico.”

Livro Google, a História

Para quase toda empresa, o maior desafio não é a falta de idéias, mas saber administrar bem a inovação, de forma que ela proporcione o retorno pretendido para o investimento feito pela empresa em termos de dinheiro, tempo e pessoal. Em TI não é diferente. Retorno significa, em termos claros, dinheiro. Se você não conseguir descrever como sua idéia gerará riqueza, você não irá longe como inovador. Antecipe-se a questões comerciais básicas: Qual é a proposição de valor para o cliente? Como esta idéia criará vantagem competitiva? Sua idéia de negócio talvez ainda não esteja completa, mas é preciso demonstrar que você está atendo a estas questões.

No tradicional funil da inovação (Clark e Wheelwright, 1993), a análise financeira da proposta de inovação é realizada na etapa de viabilidade do projeto (business plan), antes da execução do projeto. Técnicas de análise financeira a exemplo de NPV, IRR, IL, Payback e Análise de Riscos são utilizadas nesta etapa para avaliação do ROI da Inovação. A Curva de Caixa da Inovação, encontrada no livro “Payback, a Recompensa Financeira da Inovação” da editora Campus e do Boston Consulting Group, tenta fornecer algumas contribuições de uma avaliação de todo o processo de inovação, conforme figura acima. Na curva, os custos iniciais durante a concepção e captura das idéias são baixos se comparados com a execução do projeto e da comercialização. O desafio é manter os investimentos em níveis aceitáveis na fase do projeto. O retorno virá com os ganhos após o lançamento do produto no mercado, que deve ocorrer no menor tempo possível (time-to-market).

Além do livro citado neste artigo, recomendo a leitura do tradicional “Gestão da Inovação” de Tidd et al. e do excelente “Gestão de Idéias para Inovação Contínua” de Barbieri et al. Este último explora os conceitos de Demand Pull (inovação a partir das necessidade dos clientes) e Science Push (inovação a partir de P&D ou idéias). A inovação no conceito de Demand Pull também é explorada de forma brilhante no livro “Toyota – A Fórmula da Inovação”. Bem, são temas bem interessantes que podem ser estudados e aplicados em tecnologia da informação. Voltando ao texto de Silvio Meira na HSM Management. Segundo ele: “O que move a inovação é a conexão, inclusive a do capital”. Eis uma lição valiosa. O caminho é possível. Vamos em frente !!!

A importância da implantação conjunta do ITIL com a ISO 20000

2009-04-25T06:04:00.000-07:00

O ITIL v3 é uma referência para que as empresas implantem uma estratégia de serviços que envolva gestão da demanda, valores financeiros previstos para os serviços e a inclusão deste pipeline no portfolio. Também abrange um projeto do serviço que considera aspectos importantes como continuidade, capacidade, segurança e níveis de serviços. Na sequência é realizada uma transição do serviços para a produção, incluindo os processos de ativos/configurações de serviços, mudanças, release, testes e avaliação. Quando o serviço está pronto e devidamente aprovado/testado, é realizada uma passagem para a produção. Nesta etapa, processos e funções como service desk, incidentes, eventos e acesso são utilizados. Finalmente é apresentada uma referência para melhoria contínua, considerando algumas práticas recomendadas por Deming.

Estaria tudo certo, não fosse um detalhe. Sendo o ITIL uma referência, como garantir a implantação de forma efetiva e a sua sustentação ao longo do tempo?. O problema da abordagem apresentada é que o ITIL não garante que os processos sejam realmente implementados nos seus requisitos mínimos. Deveria existir em algum local uma determinação do tipo “deve existir um plano de capacidade !!” que pudesse ser avaliada quanto à sua eficácia. Neste aspecto, a ISO 20000 pode complementar o ITIL. O Cobit v4.1, com seus processos de Delivery & Support, atua com propósito semelhante, porém focando em "o que fazer" sob a ótica do ciclo de vida da Governança de TI e não em Gestão da Qualidade de Serviços de TI. Idem para o eSCM que determina "o que fazer" sob a visão do ciclo de vida de Outsourcing. O Cobit v4.1 e o eSCM estão em um nível acima. É preciso arrumar a casa. Para isto existe a ISO 20000 que é um padrão internacional de qualidade, projetado para gerenciamento de serviços de TI (ITSM). Certifica a empresa e tem como base o ITIL v2 (apesar de sua estrutura já contemplar o ITIL v3 nos seus requisitos mínimos e importantes para ITSM). No Brasil temos 05 empresas certificadas e no mundo são mais de 380, lideradas pela Japão (60), Reino Unido (58), India (44), China (37) e Coréia (34).

Bem, estava outro dia lendo uma revista mensal de TI. Notei em uma matéria algumas opiniões de CIOs quanto à Qualidade de Serviços de TI. Eis três afirmações passíveis de debate:

“Na parte de processos internos e de infra-estrutura, desde o ano passado estamos nos adequando às melhores práticas do ITIL. Como a meta é fazer a adoção completa do ITIL, estamos certificando nove funcionários e vamos contratar outros três já certificados. Essa adequação implicará a revisão de processos e da documentação”.

“Na área de governança e arquitetura de TI, nos baseamos nas melhores práticas do Itil e do Cobit, pois precisamos estar em conformidade com a Sarbanes-Oxley. Isso já garante a qualidade das informações e dos processos.”

“Em segurança, seguimos a norma ISO 27001. Já em relação à qualidade dos serviços de TI, temos um scorecard com indicadores como disponibilidades dos sistemas e custos”

Nenhuma crítica maior para as declarações acima, com exceção de que são visões bem restritas de gestão de serviços de TI. Nota-se que o foco maior está em “fazer acontecer” ou “fazer aparecer”, sem um cuidado com o melhor método ou com uma análise. Vejamos um exemplo deste raciocínio. Um CIO ao afirmar que já possui processos ITIL implantados não garante que a implantação está seguindo os requisitos mínimos de qualidade em ITSM. A ISO 20000 é um complemento do ITIL, pois atesta que as melhores práticas em gestão de serviços de TI estão efetivamente implantadas. Garante também que os processos mínimos estão sendo seguidos. O fato de acionar uma entidade externa (ex. BV, DNV ou BSI) para auditoria dos processos de forma contínua e periódica, bem como utilização de avaliações internas (auditoria interna), garante que os processos e a qualidade de serviços de TI estão sendo seguidos. Para garantir a qualidade das avaliações, é importante que sejam conduzidas por pessoas com excelente nível de conhecimento e experiência em ITIL e em Sistemas de Qualidade.

Outro aspecto importante é que a ISO 20000 garante para o ITIL alguns complementos fundamentais, como por exemplo a responsabilidade da alta direção sobre o sistema de qualidade de serviços de TI, competência, treinamento e requisitos de documentação para a execução dos processos. Tudo isto é auditado quanto à sua eficácia. Outro aspecto fundamental é a inclusão dos processos do ciclo PDCA, incluindo auditoria, registros, evidências de não- conformidades e oportunidades de melhorias com suas respectivas ações preventivas e corretivas. Processos importantes de relacionamento com o cliente (incluindo gestão de reclamações) e de gestão de fornecedores são auditados e escalados. Exige-se também um processo de melhoria de serviços com atividades bem definidas, incluindo determinações claras de entradas e saídas.

Finalmente, é recomendável que as empresas e provedores de TI considerem seriamente esta implantação conjunta. Os benefícios serão maiores do que a implantação do ITIL de forma isolada para a Gestão da Qualidade em Serviços de TI. Como dizia Gary Hamel, famoso guru e estrategista: “

“Boa parte do que está mudando simplesmente não é visto de onde você está sentado. Sua visão está obstruída. É preciso levantar-se da cadeira e buscar novos conhecimentos.”

Gary Hamel

Este alinhamento entre o ITIL e a ISO 20000 tem tudo a ver com esta busca de novos paradigmas para a gestão de serviços de TI. Eis mais um bom tema para debate com os colegas do blog.

Crise financeira mundial e os erros na gestão de riscos: O que a TI pode aprender

2009-04-18T07:10:00.000-07:00

René Stulz, professor de Finanças Corporativas da Ohio University, escreveu recentemente um brilhante artigo sobre a crise financeira mundial. Segundo ele, o estrago se deve, em parte, a falhas em sistemas convencionais de gestão de risco. O brilhante mestre aponta seis grandes erros na gestão de riscos que não foram observados. Compartilho no blog uma síntese e análise do texto, relacionando-o com situações de gestão de riscos em Tecnologia da Informação. Pode ser útil na gestão de projetos e operações pelos leitores do blog.

Bem, à medida que forem somando as perdas trazidas pela crise financeira, a gente se pergunta, aqui do nosso recanto no Brasil, como o mercado financeiro pôde ter errado tão feio. Como é que todos aqueles complicadíssimos modelos foram falhar ? aqui no Brasil, como no resto do mundo existem softwares complexos que implantam modelos como VaR (Value-at-Risk), a exemplo do Risk Metrics do JP Morgan, Corporate Risk, SAS e outros, já abordados em artigo anterior neste blog. O autor relata que é óbvio que houve uma tremenda falha na gestão de risco em quase todo o mercado.

A seguir o professor explora em detalhe cada um dos seis caminhos do erro. Repare como estes equívocos também podem ocorrer em tecnologia da informação, guardadas as devidas diferenças:

Depender de dados históricos. Modelos empregados na gestão de risco usam o passado para projetar o futuro, mas a rápida inovação financeira e tecnológica das últimas décadas fez da história um guia imperfeito.
Usar indicadores limitados. Usam indicadores que não refletem totalmente o cenário para monitorar o risco. Os dados usados na montagem de modelos são apenas parte do problema. Os fundamentos oscilam.
Ignorar riscos identificáveis. Pessoas responsáveis pela gestão do risco simplesmente ignoram muitos tipos de risco, e às vezes até criam alguns.
Ignorar riscos ocultos. Pessoas que assume os riscos volta e meia não avisam quem precisa saber – às vezes de propósito, as vezes sem querer. Na organização o risco oculto tende a crescer.
Falhar na comunicação. Sistemas de gestão de risco trarão pouca proteção se as pessoas responsáveis pela gestão do risco não souberem se comunicar com clareza.
Não administrar em tempo real. Riscos podem mudar de forma brusca e acentuada com flutuações diárias dos cenários.

Em Tecnologia da Informação, o que podemos aprender com esta crise ? Para quem conhece um pouco de finanças corporativas sabe que o método mais comum de avaliar o grau de risco financeiro é o Value-at-Risk (VaR). Existem restrições em utilizar um único modelo como este. Em tecnologia da informação seria o equivalente a utilizar um único padrão como a ISO 27005, sem observar que existem padrões que o complementam e que podem ser utilizada para melhorar a gestão de riscos de TI. Um exemplo é o Risk IT do ISACA (trabalha forte com governança) e o NIST Risk. Outro equívoco seria utilizar em projetos de TI de grande porte e complexos apenas aspectos qualitativos do processo de Gerenciamento de Riscos do PMI/PMBoK, sem considerar aspectos mais sofisticados como Monte Carlo, Métodos Estatísticos, Análise de Probabilidade e Árvore de Decisão.

Outra questão importante é considerar que riscos em TI estão envolvidos apenas com controles e segurança da informação. Trata-se de uma limitação de indicador. Tive uma experiência deste tipo na implantação da norma ISO 20000, quando foi exigido que todos os riscos possíveis deveriam ser considerados na gestão da área escopo. Por exemplo, um risco de entrega de serviço ou do não cumprimento do SLA deve ser identificado e as pessoas responsáveis pela gestão do contrato não devem ignorar este fato. Uma comunicação clara deve ser realizada para o cliente e para todos os stakeholders do provedor de TI. Não avisar quem precisa saber tem sido um dos grandes problemas de derrocada de instituições financeiras do mundo e o mesmo pode acontecer em projetos de TI. O caso do Banco Barings da Inglaterra foi muito contundente neste aspecto.

Utilizar apenas dados históricos para prever possíveis problemas de venda e entrega de serviços é um equívoco. Estar sempre atento aos cenários não deve ser tarefa apenas da alta direção. Bem, esta foi uma relação rápida dos erros apontados pelo Professor René e erros possíveis em TI. Abordagens convencionais à gestão de risco embutem muitas ciladas. Em tempos de crises este tipo de abordagem pode simplesmente ruir. Podemos utilizar estas lições em tecnologia da informação. O professor denomina isto de “gestão de risco sustentável”. Mais um bom tema para debate.

Quando um processo deve ser arte, e não ciência ?

2009-04-16T16:31:00.000-07:00

Na Harvard Business Review deste mês foi publicada uma matéria de dois professores do Dartmouth College mostrando que às vezes o movimento de padronização de processos vai longe demais. Segundo os autores, certos processos exigem o critério de um artista, e assim devem ser administrados. Gostaria de relacionar esta visão com os processos de tecnologia da informação, relatando alguns exemplos úteis para os leitores do blog.

Um processo de vendas que deu certo para infraestrutura de redes pode ser adotado para todos os serviços de TI ? ou o melhor seria que cada área tivesse seu processo específico alinhado com um processo corporativo ? faz sentido, para um provedor de TI, desenvolver e documentar um processo detalhado que siga os últimos padrões ISO ? Ou será que dar mais treinamentos e autonomia ao pessoal é o que garantiria uma qualidade superior? é possível ter mais qualidade administrando desenvolvedores de softwares como se fossem mecânicos ? É possível que um erro vire uma oportunidade de aprendizado ?

Há processos que naturalmente resistem à definição e à padronização – ou seja, que são mais arte do que ciência. Geralmente quando as suas entradas são variáveis e o cliente preza a variação nos resultados. Com alguns exemplos ficará fácil entender. A padronização de processos é ensinada em cursos de administração, é parte de programas Seis Sigma e ISO, é automatizada através de ferramentas BPM como os da BEA, Tibco e Aris e utiliza alguns modelos como SIPOC, UML, IDEF0 ou BPMn. Utilizei algumas ferramentas de BPM em clientes para produzir algumas dezenas de fluxos de processos automatizados para redução de papel, padronização, agilidade e “amarração” de atividades visando um objetivo final para o negócio, não separando processos padronizáveis ou não. Lembro também que melhores práticas de padronização são defendidas por gurus da área como Michael Hammer em seu livro “A Agenda” e Thomas Davenport no seu famoso artigo de 2005 na HBR sobre “Comoditização de Processos”, cuja representação máxima está no projeto “Process Handbook” do MIT (http://ccs.mit.edu/ph/). O PH é uma biblioteca de processos já implantados com sucesso em grandes empresas e tem utilização livre. Outro bom exemplo de padronização está na Toyota, conforme relatado em publicações como “The Toyota Way” que defende o conceito de trabalho padronizado dentro do STP (Sistema Toyota de Produção), combinada com outras práticas como Just-in-time e controles visuais para detectar desvios.

Bem, esta é a minha visão. No entanto, o problema identificado pela reportagem da HBR é que a padronização de processos pode, ironicamente, minar o próprio desempenho que pretende otimizar. Muitos processos funcionam melhor quando, em vez de rigidamente controlados, são tratados como um trabalho artístico. O Gerente deve separar todo processo artístico de processos de apoio que possam ser padronizados. Um grande vendedor de serviços de TI, por exemplo, busca em processos de vendas e sistemas de relacionamento com o cliente informações básicas e coerentes (padronizável) para ajustar seu discurso de vendas a cada cliente (não padronizável).

“A padronização exime o profissional da responsabilidade e faz com que ligue o piloto automático em vez de analisar melhor os detalhes do processo.”

"Um processo artístico precisa de indicadores externos de sucesso, como o feedback de clientes. Processos padronizados são medidos e avaliados à luz de normas e parâmetros determinados e acordados (SLA ? ), ao passo que processos artísticos são avaliados por meio da interação com o cliente."

A padronização e o controle são importantes, porém a arte utilizada em processos como vendas, inovação, gestão do conhecimento, atendimento ao cliente, desenvolvimento de software e até mesmo auditoria (porque não? ) permite uma flexibilidade, uma criatividade e um dinamismo impossíveis de serem reproduzidos por uma abordagem puramente científica. Os autores defendem que o desenvolvimento de uma nova aplicação em geral exige a iteração constante com cliente e decisões de simplificar o trabalho (imagine agora com os métodos ágeis). O atendimento ao cliente em um service desk deve ter flexibilidade de abandonar o roteiro e fazer o que achar melhor para o momento (lembrem-se o que a reportagem cita: existem variações e situações diferentes nas solicitações dos clientes e que exigem flexibilidade). Quanto a este ponto, lembro de um trecho do livro “O Futuro da Competição” de C.K. Phahalad, famoso guru de estratégia”, que manifesta sua irritação pelo fato dos atendentes de service desk serem geralmente avaliados em termos de produtividade e metas estipuladas em processos, em vez do valor e do retorno do atendimento para o cliente.

Bem, os autores concluem que tanto arte como ciência têm um papel importante nos processos da empresa. Não se pode pensar apenas em ganhos de produtividade e metas sem pensar nas pessoas, inovação e relacionamento com o cliente, e vice-versa. Lembro-me das lições do STP (Sistema Toytota de Produção) sobre melhoria contínua. Quando um problema surge, qualquer profissional da equipe é responsável e dispõe de autonomia para achar uma solução. Na Toyota, espera-se que cada um aja de acordo com o acha certo. Autoridade e responsabilidade cabem ao indivíduo, e não a um cargo ou tempo de serviço. Coloca-se a responsabilidade pela qualidade nas mãos dos membros da equipe. Eles sentem a responsabilidade, eles sentem o poder. Eles sabem que são levados em consideração. Eis um bom exemplo de arte que pode ser adaptado aos processos de TI.

Desafios em contratos de outsourcing de TI

2009-04-10T17:13:00.000-07:00

Estava no final de 2008 apresentando um artigo científico no Congresso Nacional de Engenharia de Produção (ENEGEP) no Rio. Durante o evento, mantive um debate com o Professor Marcelo Pessoa da Poli/USP sobre algumas razões de um relacionamento bem-sucedido Cliente x Provedor de TI. Chegamos à conclusão que a busca da inovação, sem perder o foco em redução de custos e melhoria contínua, é uma meta a ser buscada sempre. Estudei algumas publicações internacionais que falam sobre o mesmo assunto. Compartilho com os leitores do blog algumas reflexões. Podem comentar à vontade, relatando situações que comprovam ou não o descrito a seguir.

Uma questão fundamental neste tipo de relacionamento é a percepção clara que os valores mudam ao longo do contrato. Em um primeiro momento existe uma preocupação muito forte em redução de custos, porém mudanças ocorrem e o provedor de TI deve estar preparado para entregar outros diferenciais como qualidade e inovação. Sendo realista, o cliente está preocupado inicialmente em uma TI mais econômica, motivo pelo qual ele busca uma terceirização, tentando no mínimo manter a qualidade atual. Após ganhar a concorrência o provedor inicia a implantação do contrato, colocando em prática o que foi acordado. Repare que, do ponto de vista estratégico, o processo de outsourcing é iniciado antes mesmo da colocação e resposta a uma RFP (Request for Proposals), conforme demonstrado na figura abaixo extraída do artigo "A Negotiation Approach to Project Sales and Implementation" do Project Management Journal do PMI (disponível em http://www.pmi.org/).

Avançando um pouco nesta hipótese de redução de custos, em um relacionamento longo, o outsourcing de TI inicia-se com uma percepção da alta direção do cliente de que a TI representa uma função “non-core” ou não principal do negócio. Na realidade é enxergada como uma “commodity”, onde os custos precisam ser reduzidos por meio de contratação de um provedor de TI externo. Os contratos geralmente são ganhos neste aspecto (custo), ou seja, quando o cliente tem a evidência que poderá reduzir os custos de TI do serviço em uns 20%, por exemplo. Existem riscos para futuras iniciativas de qualidade e inovações nesta fase inicial. Pode ocorrer redução de motivação para inovar por parte das unidades de negócios, já que todo contato com o provedor de TI passa a ser do CIO e da sua área de TI. O provedor de TI, por sua vez, fica com o desafio de manter o contrato rentável apesar das pressões do cliente em redução de custos. Convive-se, em alguns casos, com infra-estrutura do cliente muito desatualizada e equipe do contrato altamente enxuta, o que eleva ainda mais a pressão. O relacionamento é dominado neste ponto por constantes negociações em torno de escopo e custo acordado, não sobrando tempo para mais nada, além de manter o operacional rodando. A TI neste ponto é mais barata, e só.

Em uma segunda fase, ocorre uma insatisfação compartilhada entre provedor e cliente com a fase anterior. Neste aspecto, os objetivos de aumento de qualidade são requisitados para que a TI possa estar mais orientada ao negócio. O cliente está disposto a rever as capacidades de TI como também negociar quais os recursos ideais para prestação de bons serviços. O provedor avalia quais as melhores plataformas de práticas, processos, hardware e software para aumento da qualidade e quem poderá financiá-los. Temas como best practices e benchmarking são citados com freqüência. Um bom exemplo disto é a implantação da ISO 20000 ou de uma ISO 9001 em um contrato de um provedor de TI. Passa a existir então uma TI melhor.

Em uma terceira e última fase existe uma clara preocupação em adicionar valor ao negócio do cliente através de inovações. Voltando à nossa realidade, podemos citar exemplos como automação de processos de negócios, introdução de um método de medição/reporte de TI baseado em metas do negócio (ex. INDG ou Balanced Scorecard), uma solução efetiva de resolução de problemas, portal de conhecimento para colaboração e busca de soluções por toda a empresa, uma base de dados de configurações (CMDB), integrada de forma automatizada com demais bases de dados de negócios e de sistemas. Tudo isto alinhado com o negócio. Passa a existir então um negócio do cliente melhor.

O quadro mostrado acima com as três visões e mais detalhes sobre o tema podem ser obtidos no trabalho “Outsourcing: From Cost Management to Innovation and Business Value” do California Management Review, disponível como estudo de caso da Harvard Business School em http://www.hbs.edu/.

Para finalizar, importante ressaltar que a sequência apresentada (custo, qualidade e inovação) deve ser bem gerenciada. Não adianta tentar implantar no inicio do contrato um serviço inovador, quando isto representará “aumento de custo” não suportado pelo contrato e difícil de negociar (principalmente em época de crise financeira). Também não se deve insistir apenas na redução de custos e na implantação de uma simples documentação dos processos sem pensar em qualidade e inovação. No longo prazo, isto não se sustenta, podendo levar à perda do contrato em clientes mais exigentes. Bem, existe um grande desafio e pressão para os provedores de TI reduzirem custos e ao mesmo tempo aumentar valor dos contratos através da qualidade e inovação, tudo isto em um tempo cada vez mais curto. Eliminar este trade-off será um desafio constante. Para citar um exemplo real, participei de uma concorrência em 2008, onde o cliente exigia respostas claras para duas questões básicas:

“Possui algum diferencial em relação ao serviço, que possa proporcionar melhorias de processos, qualidade e/ou redução de custos ?“

“Gostaria de propor funcionalidades adicionais aos requisitos apresentados, que seriam vantajosas ao nosso negócio ?“

Pretendo em um próximo artigo indicar algumas alternativas para o assunto dentro do conceito de inovação de valor. Postarei também um exemplo prático de gráfico de melhoria de qualidade baseado no modelo de Qualidade Total de Joseph Juran (classificação tempo x desempenho de contratos).

Gestão de Riscos: Uma Avaliação do Risk IT Framework do ISACA/ITGI

2009-04-10T15:06:00.000-07:00

Risco não é um conceito novo. A Teoria Moderna das Carteiras (base do que conhecemos como riscos corporativos) originou-se do trabalho pioneiro de Markowitz por volta de 1950 e ainda é muito estudada em Finanças Corporativas e MBA’s pelo mundo afora. Esta teoria está baseada nos conceitos de retorno e risco. Risco assumiu sua justa posição de destaque somente mais recentemente, seguindo-se a escândalos internacionais, como aqueles envolvendo nomes como Barings Bank (1997), Enron (2001) e mais recentemente com o Lehman Brothers e AIG.

Os três conceitos fundamentais para qualquer investidor são retorno, incerteza e risco. Retorno pode ser entendido como a apreciação de capital ao final do horizonte de investimento. Infelizmente, existem incertezas associadas ao retorno que efetivamente será obtido ao final do período de investimento. Qualquer medida numérica desta incerteza pode ser chamada de risco. Retorno e risco estão presentes em qualquer operação no mercado financeiro e também em tecnologia da informação. Existe um ditado antigo: “no risk, no fun”. Se o retorno é alto, geralmente o risco acompanha. Enquanto a definição de retorno é intuitiva, o mesmo não se pode dizer sobre risco. Isto porque o risco é um conceito “multidimensional” que cobre quatro grandes grupos:

Risco Operacional
Risco de Mercado
Risco de Crédito
Risco Legal

Vários frameworks foram desenvolvidos para riscos corporativos, sendo os mais conhecidos o VAR – Value at Risk e o COSO Enterprise Risk Management, assim como softwares para gerenciar estes riscos. Alguns sistemas mais conhecidos e que tive contato são o Risk Metrics e Corporate Metrics do JP Morgan, utilizados pela maior parte das instituições financeiras mundiais e por empresas como a Braskem e também o Risk Navigator, utilizado no Brasil pela Vale do Rio Doce. No que se refere a riscos operacionais e, sendo mais preciso, aos riscos de tecnologia da informação, existem alguns frameworks conhecidos como o NIST Risk Management e a ISO/IEC 27005.

Eis que chega mais um modelo no mercado e que eu gostaria de compartilhar com os colegas da CPM Braxis. Trata-se do Risk IT do ISACA. Este novo framework foi lançado em fevereiro/2009 e ainda está em formato de draft para consulta e contribuição por parte dos seus associados. A audiência deste modelo são os CIOs, CSOs, CFOS e Gestores de Negócios em geral. O Risk IT inclui três áreas de conhecimento: Risk Governance, Risk Evaluation e Risk Response. O framework é bastante extenso. As três áreas de conhecimento são desdobradas em 46 processos. Uma breve descrição de cada uma delas é mostrada abaixo:

1. Risk Governance

Estabelecer e manter uma visão comum dos riscos
Integração com Gerenciamento de Riscos Corporativos
Incluir consciência de riscos nas decisões de negócios

2. Risk Evaluation

Coleta dados
Analisar os riscos
Manter um perfil dos riscos.

3. Risk Response

Articular os Riscos
Gerenciar os Riscos
Reagir aos Eventos

Fazendo uma analogia com o modelo do NIST, Risk Evaluation (Risk IT) está bem próximo do Risk Assessment. O Risk Response (Risk IT) está alinhado com os processos de Risk Mitigation do NIST. Comparando também com a ISO 27005, o Risk Evaluation (Risk IT) está relacionado ao Risk Assesment / Risk Analysis. Já o Risk Response (Risk IT) pode ser relacionado ao Risk Treatment / Risk Acceptance. A ISO 27005 também utiliza outros processos como Risk Communication e Risk Monitoring and Review que também podem ser relacionados ao Risk Response. O interessante da ISO 27005 é que os processos são colocados dentro de um PDCA (a exemplo de outras normas ISO). O NIST Risk Management possui uma extrema facilidade de entendimento e aplicação. Já uma vantagem do Risk IT é que, seguindo a linha do CobiT, para cada processo são apresentadas metas vinculadas com indicadores de negócio, processo, e de atividades, matriz RACI, input/output etc.

A diferença maior do Risk IT em relação aos demais modelos está no conceito de Risk Governance ou alinhamento do risco de TI com os demais riscos corporativos. Outra vantagem é a sua total integração com o CobiT v4.1 (Governança de TI) e Val IT (Gestão de Valor em TI). Por trás de todas as interfaces está o know-how do ITGI/ISACA. Não percebi em outros modelos que eu conheço um nível de sinergia tão forte para tomada de decisões em riscos de TI. A área de Risk Governance envolve alguns processos como Accountability de Riscos e Adaptação dos riscos de TI com os riscos organizacionais.O processo de conectar os riscos operacionais de TI com os riscos corporativos (financeiro, crédito e legais) ajuda a formar uma visão comum da visão dos riscos. Também foram montados processos para realizar o relacionamento com o COSO ERM.

Conforme mostrado na figura acima, o relacionamento do Risk IT com o Cobit e com o Val IT funcionará da seguinte forma: As atividades de TI e os eventos relacionados são controlados pelo Cobit, os quais são avaliados quanto aos seus riscos e oportunidades, gerando informações para a Gestão dos Riscos (IT Risk) e Gestão de Valor (Val IT), responsáveis pela diretrizes. Na figura abaixo, apresento o modelo geral com todos seus processos e relacionamentos necessários.

Após as contribuições, o objetivo do ITGI / ISACA será lançar o framework ainda neste ano de 2009. Na minha opinião, será muito útil em termos de complementação aos modelos existentes. Vamos esperar para ver.

A Certificação de Engenheiro de Qualidade de Software

2009-04-10T08:10:00.000-07:00

Saiu o ranking do ultimo exame de CSQE (Certified Software Quality Engineer) da ASQ (American Society for Quality). A prova foi realizada em dezembro/08 em vários locais do mundo, incluindo o Brasil. Esta certificação concorre de perto com a CSQA (Certified Software Quality Analyst) e a CSTE (Certified Software Tester) da QAI, bem mais conhecidas e populares, principalmente entre os indianos. O currículo do CSQE abrange o conteúdo das duas certificações da QAI e tem uma base muito forte em Qualidade Total, dada a tradição da ASQ nesta área. São apenas 4.300 CSQEs contra mais de 50.000 do CSQA/CSTE. A maior experiência requerida, prazo de validade, o currículo maior, a falta de disponibilidade no Prometrics e o fato do exame do CSQE ser realizado apenas em inglês pode explicar esta diferença. Atualmente mais de 50% dos aprovados concentram-se nos EUA.

Quanto à prova, o currículo abrange Qualidade Total, Estatística, Qualidade de Software, Custos da Qualidade, Engenharia de Requisitos, Métricas de Software, Técnicas Analíticas, Métodos Ágeis (Scrum/XP/TDD), Revisão&Inspeção, Planejamento e Projetos de Testes, Configurações, Engenharia Reversa, Reuso, Gestão de Projetos, Arquitetura de Aplicações, Sarbanes-Oxley, Lean Six Sigma (básico), CMMI, ISO 9126, ISO 12207, ISO 15504, SWEBoK e outros temas relacionados. São 160 questões em 04 horas. O tempo é muito pouco, já que existem cálculos estatísticos e matemáticos (ex. APF, Complexidade Ciclomática e Confiabilidade).

A aprovação está em torno de 50% a 60% nos EUA e menor em outros países Temos atualmente apenas cinco pessoas com esta certificação no Brasil. O curioso é que existe alto interesse pelo CSQE em outros países. Nos seis últimos exames foram 1.500 aprovados, sendo apenas uma única pessoa da nossa terra. Os números refletem bem alguns países que estão investindo fortemente em software business: Coréia, Israel, Índia, China e Japão. Alguns outros países como a Argentina e Costa Rica estão crescendo neste ranking.

Recomendo esta certificação para todos os brasileiros envolvidos ou que gostam de Qualidade de Software. O BoK, os valores detalhados, preparação e datas dos próximos exames estão disponíveis no seguinte endereço:

http://www.asq.org/certification/software-quality-engineer/index.html

O próximo exame no Brasil está previsto para 06/06/2009 e o valor da inscrição é de US$ 390.00 para os não associados da ASQ. Há necessidade de preencher um application. Recomendo também adquirir o curso CSQE Primer do Quality Council of Indiana por US$ 150.00, além de um bom livro de Qualidade Total em inglês (preferencialmente o Juran’s Quality Handbook) por US$ 120.00. Por segurança pedir emprestado em bibliotecas livros clássicos de Engenharia de Software (sempre em inglês) como o Pressman e o Sommerville e também o "Metrics and Models in Software Quality Engineering" de Stephen Kan, livro recomendado pela ASQ e que é bastante solicitado na prova.

A Crise e os Recursos Estratégicos das Empresas

2009-04-08T19:02:00.000-07:00

Na revista Exame de fevereiro/2009 foi publicada uma matéria sobre a difícil decisão de cortar gastos em momentos de crise. Segundo a revista, a crise vem colocando uma situação algumas vezes inevitável diante dos executivos: a demissão em massa. Mas como definir rapidamente como e onde demitir sem comprometer o futuro? Desde o final do ano passado, quando os primeiros sinais da crise apareceram por aqui, executivos e empresários brasileiros reincorporaram a seu vocabulário expressões como "corte de pessoal" e "demissão em massa. A redução de cerca de 4.000 empregos em fevereiro na Embraer foi um claro sinal de que a crise chegou ao mercado real.

Diante do cenário atual, um deslize comum é a tentação de seguir o caminho mais simples e rápido e baixar metas iguais de cortes para todas as áreas da empresa. A revista diz que o preço a pagar por uma decisão tomada às pressas pode ser alto. Para determinar onde fazer os cortes de maneira eficiente, os especialistas recomendam avaliar detalhadamente toda a estrutura da companhia. Muitas empresas ainda fazem escolhas sociais - tempo de casa, pais de família, necessidades econômicas. Embora se justifiquem do ponto de vista humanitário, esses critérios não são necessariamente justos com quem dá mais resultado ou tem maior potencial. Para demitir 1 300 de seus funcionários, a Vale analisou as avaliações de desempenho de todos os funcionários das áreas atingidas pelos cortes. Os que tinham resultados mais consistentes ao longo do tempo, cumpriram ou ultrapassaram suas metas anuais e tinham características de liderança foram mantidos. Os donos das piores avaliações entraram no corte. Em geral o marketing, o contato com o cliente e desenvolvimento de produtos são áreas que não podem ser mexidas. A matéria completa da Revista Exame está disponível em:

http://portalexame.abril.com.br/revista/exame/edicoes/0937/gestao/decisao-mais-dificil-422196.html

Já a revista Harvard Business Review na sua edição de dezembro/08 publicou um artigo de Kaplan & Norton (os mesmos criadores do Balanced Scorecard) sobre o mesmo assunto. Segundo eles, em uma reação instintiva, muitos executivos cortam gastos discricionários por toda a organização durante uma crise econômica. Só que esta poda brutal e indiscriminada é um grande erro, pois não faz distinção entre programas operacionais de curto prazo e estratégicos de longo prazo. Salvo se a crise estiver ameaçando a existência da empresa, o que seus executivos devem fazer é eliminar excessos e ineficiência operacionais – e não modificar ou sacrificar iniciativas estratégicas a exemplo de inovação e gestão do conhecimento, que geram recursos para a vantagem competitiva de longo prazo.

Para ajudar a empresa a preservar e fortalecer seus programas estratégicos, os autores criaram uma uma nova categoria de despesas – despesas estratégicas (ou StratEx, no inglês) – para suplementar as categorias tradicionais de despesas de capital e despesas operacionais (OpEx). Kaplan & Norton constataram que, se não forem separadas das demais categorias e protegidas, as StratEx serão vistas como discricionárias pela diretoria. Diante de dificuldades econômicas de curto prazo, é comum a diretoria deferir ou transferir fundos de iniciativas estratégicas para honrar metas financeiras de curto prazo – um dos principais motivos da tremenda dificuldade da maioria das organizações em sustentar processos de execução da estratégia. Finalmente, criar uma categoria de financiamento de StratEx ajuda a empresa a reunir recursos para o futuro enquanto elimina os excessos do passado.

Para quem estiver interessado em maiores informações sobre o conceito de StratEx pode encontrá-lo no 4º. capítulo do livro de 2008 “A Execução Premium” de Kaplan & Norton.

Nicholas Carr e a Grande Mudança

2009-04-07T16:53:00.000-07:00

Estou lendo o livro de Nicholas Carr, “A Grande Mudança, Reconectando o Mundo, de Thomas Edison ao Google”. Apesar de não ser tão recente (2007), e o assunto “Utility Computing” já ter sido bastante debatido, recomendo a leitura por ser um tema importante e atual. Carr descreve que o mundo da tecnologia está às vésperas de uma nova e profunda transformação.

“Em um futuro próximo, tudo o que acontece dentro do computador - desde o processamento até o armazenamento de informações - deve migrar para a internet.“

Os documentos, assim como os aplicativos usados para criar e modificar esses arquivos, estarão guardados em servidores espalhados pela internet. O PC vai ser apenas um dos meios de acessar essas informações, a qualquer hora, de qualquer lugar. Na esfera das empresas, a mudança representa o desaparecimento de grandes servidores, por exemplo. A idéia é poderosa e tem implicações profundas e imediatas para a indústria de software e hardware, na qual prosperaram potências inquestionáveis como Microsoft e IBM. No cenário delineado por Carr, ninguém mais precisará comprar um software para ter em sua máquina o programa que deseja. Ele será um serviço disponível via internet, pago em mensalidades ou até mesmo gratuito.

O mais interessante do livro é a relação que o autor faz entre esta transformação atual e o serviço de geração elétrica há um século. O grande personagem da época foi o inventor e empresário americano Thomas Edison, que no final do século 19 levou a eletricidade para dentro das casas. A visão de Edison não só transformou o funcionamento das empresas mas alterou o ritmo de vida e a cultura da sociedade.

“Inicialmente os donos das fábricas precisavam estar também no ramo de produção de energia. Após um certo tempo, podiam fazer suas máquinas funcionarem com a corrente elétrica gerada em usinas distantes por grande companhias de serviços públicos, e que chegava às suas fábricas por meio de uma rede de cabos. “

O que garantiu este triunfo não foi a tecnologia, e sim os processos econômicos. As fornecer a muito compradores a energia gerada em centrais elétricas, as companhias chegaram a uma economia de escala em termos de produção de energia, algo que não era páreo para nenhuma fábrica individual. Para os donos das indústrias, tornou-se uma necessidade competitiva plugar as fábricas à nova rede elétrica para terem acesso a uma fonte de energia mais barata.

É claro que todas as analogias e os modelos históricos têm seus limites, e a tecnologia da informação difere da eletricidade de muitas formas importantes. Mas, elas têm grandes similaridades. Não precisam ser produzidas no local em que serão usadas. É um serviço que gera inúmeros usos que adquirem vida própria. Em um plano econômico, ambas são usadas por todo o tipo de consumidor para fazer todo o tipo de coisa e fornecem imensas economias de escala. Diferente, por exemplo, ao sistema ferroviário. Depois que os trilhos são assentados, você só pode fazer uma única coisa com eles: fazer circular trens para um lado e para outro, levando carga ou passageiros.

Conceitos como Web 2.0, Wireless, Mobile Business, Computação nas Nuvens (Cloud Computing) e SaaS (Software como Serviço) já refletem, embora em um estágio inicial, a transformação preconizada por Nicholas Carr. Recomendo uma matéria sobre Google e Computação nas Nuvens que saiu no Mundo S.A. da GloboNews em 2008, disponível em:

www.youtube.com/watch?v=IdRW8FAc6IA

Problemas como segurança, latência, nível de serviço, propriedade da informação e outras restrições ainda impedem a utilização em massa do Cloud Computing. Neste aspecto, quem não se lembra dos problemas (até maiores que estes) no inicio do uso da internet ou até mesmo do internet banking (segurança). Segundo Nicholas Carr, o mesmo aconteceu com a eletricidade. No inicio, era uma força imprevisível, ainda não domesticada, e que modificava tudo em que tocava. Como no caso dos sistemas de computação atuais, todas as empresas tinham de descobrir como empregar a eletricidade em seus negócios, fazendo mudanças radicais e freqüentes em seus processos produtivos e em suas formas de organização.

“Tudo estará na grande nuvem e será mantido por empresas que serão responsáveis pela infra-estrutura operacional.”

Finalmente, a minha visão é que não chegaremos ao extremo preconizado por Nicholas Carr:“Os departamentos de TI não terão muito que fazer depois que a computação corporativa migrar de data centers privados para a nuvem”. Mas que teremos escalabilidade, redução de custos, maior retorno sobre o investimento e utilização ideal dos recursos, isto com certeza ocorrerá. O difícil cenário econômico em 2009 e dos próximos anos irá exigir dos departamentos de TI e das empresas de outsourcing ações inovadoras. Esta com certeza será uma delas.

Gerenciamento de Projetos e a Certificação IPMA

2009-04-07T16:26:00.000-07:00

O mercado utiliza como padrão de gerenciamento de projetos a metodologia americana PMI (Project Management Institute), com seu guia de práticas PMBoK e sua certificação mais conhecida, o PMP (Project Management Professional). Existe, no entanto, outros padrões também utilizados como o IPMA (internacional) e o Prince2 (inglês). Pretendo passar para vocês uma visão do IPMA – http://www.ipma.ch/ (International Project Management Association) e suas certificações. Tenho a certificação PMP, com a qual já trabalho há algum tempo. Recentemente obtive a certificação IPMA-D (Certified Project Management Association) e passei a trabalhar também com esta prática para gerenciamento de projetos. Gostaria de compartilhar alguns conhecimentos com os leitores do blog.

O IPMA foi fundado em 1965. É um padrão europeu, com sede na Suíca e associações locais em 45 países do mundo. Por exemplo, na Inglaterra existe a APM (Association of Project Management), na Dinamarca a ADPM (Association of Danish Project Management), na China o PMRA (Project Management Research Commitee) e no Brasil temos a ABGP – http://www.abgp.org.br/ (Associação Brasileira de Gerenciamento de Projetos), com sede em Curitiba. O Congresso Mundial de 2008 foi realizado na Itália e o próximo será na Finlândia. O código de melhores práticas é o ICB (IPMA Competence Baseline 3.0), equivalente ao PMBoK, com algumas particularidades. Por exemplo, permite-se que cada país realize alterações para as certificações, adequando o manual à sua realidade. No Brasil a ABGP possui o RCB – Referencial Brasileiro de Competências, disponível na página da ABGP. Outro detalhe é que o ICB possui alguns processos diferentes em relação ao PMBoK (alguns são tratados como input ou output neste código de práticas), como por exemplo Aspectos Comportamentais do Gerente do Projeto, Gestão de Conhecimentos, Gestão de Meio-Ambiente, Gestão de Aspectos Legal e Gestão de Informática. Para quem acompanha publicações em gerenciamento de projetos, uma das revistas brasileiras mais conhecidas e que recebe patrocínio da ABGP é a Revista Mundo PM, publicada em Curitiba/PR. Reparem que na maioria das edições os artigos internacionais são provenientes da Inglaterra, Suécia, Finlândia, Noruega, França e Itália, exatamente onde o IPMA é mais forte.

Para quem estiver interessado nesta certificação, na página da ABGP constam as datas programadas das provas para 2009 (média de quatro por ano). Os exames são realizados em Curitiba e em Belo Horizonte, onde se concentram 90% das certificações brasileiras. O motivo é que a ABGP está localizada em Curitiba e em BH existem incentivos de profissionais conhecidos em gerenciamento de projetos no Brasil: Ricardo Vargas e Darci Prado (INDG).Existe expectativa do exame ser realizado em outros locais.

Bem, a certificação IPMA está projetada em quatro níveis:

A – Certified Project Director capacidade de gerenciar portfolio e programas complexos.
B – Certified Senior Project Manager: capacidade de gerenciar projetos complexos. Mínimo de 05 anos de experiência.
C – Certified Project Manager: capacidade de gerenciar projetos menos complexos. Mínimo de 03 anos de experiência.
D – Certified Project Management Associate: capacidade de aplicar conhecimentos de gerenciamento de projetos dentro dos projetos.

Fazendo uma comparação com o PMI: Na teoria, a certificação de nível A do IPMA equivaleria ao PgMP do PMI, as certificações de níveis B/C equivaleriam ao PMP e a de nível D (CPMA) ao CAPM. Isto na teoria, pois na prática não é exatamente assim. Na candidatura, exige-se toda a documentação necessária, incluindo curriculum vitae completo (no PMP é por amostragem). As provas são realizadas em duas etapas: a primeira com questões objetivas (50 questões) e abertas (05 questões principais desdobradas em 20 secundárias) e a segunda etapa com uma entrevista com grau de complexidade conforme o nível da certificação (no nível D este requisito está sendo implementado aos poucos).

As questões descritivas são direcionadas para validar o real conhecimento do candidato em project management. É fornecido um tema e solicitado a criação de todo um projeto, incluindo Project Charter, Declaração de Escopo, Plano de Projeto, Plano de Riscos, WBS, Dicionário de WBS, Cronograma, Deliverables, Determinação do Caminho Crítico, Status Report, Relatório de Lições Aprendidas , Gestão de Conhecimento, Automação da Gestão do Projeto etc. Tudo isto em 04 horas de prova escrita (ainda não está disponível no Prometrics).

Atualmente não temos nenhum profissional no Brasil no nível A (no mundo são apenas 200). Temos 06 profissionais no nível B, 08 no nível C e 75 no nível D. Total de 91 profissionais certificados em IPMA no nosso país, o que é muito pouco, considerando que existem mais de 6.000 PMPs no Brasil e também pelo valor e prestígio do IPMA nos países europeus (pode fazer diferença em negócios para esta região). Para finalizar, o IPMA pode complementar o PMI de várias formas. A sua visão é mais internacional, uma vez que cada país possui o seu guia de melhores práticas em Project Management, conservando o núcleo do ICB. Também fornece visão mais clara de processos como gestão de conhecimento, tecnologia da informação, meio-ambiente, aspectos legais como também aspectos comportamentais para o gerente do projeto, assuntos fundamentais em qualquer projeto.

Open Innovation !! Open Source !! Open Choice ...

2009-04-04T12:29:00.000-07:00

Muito se tem falado e escrito a respeito da inovação aberta e suas diversas aplicações. Henry Chesbrough, do Center for Open Innovation da Universidade de Berkeley (http://openinnovation.haas.berkeley.edu/), disseminou esta expressão através do seu livro Open Innovation (ainda sem tradução para o português). Ele afirma que o conceito de Inovação Aberta (Open Innovation) quebra o paradigma tradicional da Pesquisa & Desenvolvimento feito a portas fechadas, por uma única empresa. Este conceito trata a inovação como um sistema aberto onde tanto idéias externas e internas são debatidas e as melhores alternativas são selecionadas. Um dos grandes benefícios desse modelo é que as empresas conseguem dividir os riscos e custos do processo de inovação.

Don Tapscott em seu livro Wikinomics mostra que a nova arte e ciência se baseiam em quatro novas e poderosas idéias: abertura, peering (ausência de hierarquia) compartilhamento e ação global. Esses novos princípios estão substituindo algumas velhas doutrinas dos negócios. Empresas inovadoras como a P&G são muito diferentes das multinacionais hierárquicas, fechadas, cheias de segredos e isoladas que dominaram o século anterior.

“O objetivo é deixar que a maior parte da atividade de pesquisa aconteça nas redes cientificas. As empresas devem se ater a solucionar os difíceis problemas de orquestração dos negócios e recursos.”

Don Tapscott, Wikinomics

Já o modelo Open Source é um exemplo claro do modelo de inovação aberta, pois envolve colaboração entre empresas, comunidade de desenvolvedores, clientes e parceiros. O modelo Open Source difere do modelo tradicional em basicamente dois aspectos: o processo de desenvolvimento, que é essencialmente uma produção colaborativa e a filosofia de propriedade intelectual, que permite a livre distribuição do código fonte, bem como o direito de modificá-lo.

" O modelo Open Source é um belo exemplo de como empresas podem atuar em ecossistemas complexos combinando inovações internas e externas. "

Conforme Sergio Taurion da IBM, Open Innovation com Open Source pode se dar de várias formas. Podemos identificar o modelo de “Pooled R&D”, tipicamente representado pelos projetos Linux e Mozilla, onde diversas empresas e a comunidade pesquisam e desenvolvem o software de forma colaborativa. Outro modelo é o Spinout representado pelo Eclipse que é um exemplo prático e bem sucedido do modelo de Open Innovation, onde empresas concorrentes podem criar redes de inovação, cooperando no desenvolvimento de softwares Open Source, que servirão de base para produtos específicos (proprietários), com os quais concorrerão no mercado.

No Livro The Game-Changer ou “O Jogo da Liderança”, A.G. Lagley, CEO da P&G e o guru Ram Charam mostram como funciona a inovação aberta na Procter & Gamble. O principal radar é o portal Connect & Develop, criado em 2003. Ele está conectado com outros quatro portais: NineSigma, yet2, YourEncore e Innocentive. Segundo os autores, a principal característica do portal C&D é a disposição de todas as pessoas da P&G de se manterem psicologicamente abertas a novas idéias e levá-las a sério, independentemente de sua origem, desenvolvendo, dessa forma, uma rede de inovação aberta e global que possa se conectar com os pesquisadores ao redor do mundo e os melhores produtos para serem reaplicados. No nosso mercado de tecnologia da informação, empresas como IBM e TCS já estão bastante avançadas neste conceito. Algumas utilizam a expressão Co-Innovation (Collaboration Innovation) para denominar esta nova onda.

Em 2008 ocorreu em São Paulo o Open Innovation Seminar 2008, que deverá se repetir em 2009. Este evento contou com a presença do Henry Chessbrough e com pesquisadores de empresas nacionais e internacionais que já estão praticando em larga escala este tipo de inovação, a exemplo da Embraer, IBM e Natura. Os vídeos deste evento estão disponíveis no youtube. Recomendo o vídeo com a palestra de Cesar Taurion sobre as diversas iniciativas da IBM relacionadas com o tema (Innovation Jam, Institute for Business Value, GIO, Co-Innovation e outras), disponível em:

www.youtube.com/watch?v=ZAH2oLKY_k8&feature=PlayList&p=A9FDE113E96601D4&index=7

No youtube, também pode ser encontrado um excelente vídeo de um evento realizado na Universidade de Berkeley pela IBM e British Telecom sobre o assunto. Recomendo o vídeo sobre Open Innovation in Services com Steve Wright, Head of Strategic Research da British Telecom. É interessante o debate entre o palestrante e o brasileiro Jean Paul Jacob, cientista da IBM e professor da Caltech.

www.youtube.com/watch?v=g7eRgHWQCZc

Finalmente, diante da cada vez maior disseminação da open innovation e do open source, como também diante do atual cenário de crise mundial, é de se esperar que veremos cada vez mais artigos e cases de utilização dos dois conceitos em conjunto. É a ciência cada vez mais a serviço do negócio. Com o Open Innovation e Open Source, podemos realizar escolha (Open Choice). Como já dizia Gary Hamel, famoso estrategista, você não pode ser um inovador sem ponto de vista revolucionário. Vá além do horizonte, descobrir o não convencional, imaginar o inimaginado. Boa parte do que está mudando simplesmente não é visto de onde você está sentado. Sua visão está obstruída. É preciso levantar-se da cadeira e buscar novas experiências, ir a novos lugares, aprender novas coisas, relacionar-se com novas pessoas. Você deve tornar-se um viciado em novidades. Open Innovation e Open Source tem tudo a ver com isto.

Uma Visão Orientada a Processos do ITIL v3 Service Lifecycle

2009-04-04T12:15:00.000-07:00

A versão 3 do ITIL aborda o conceito de Ciclo de Vida de Serviços. São agora seis livros: Service Strategy, Service Design, Service Transition, Service Operation e Service Improvement, além do Introduction to the ITIL Service Lifecycle. Nota-se uma forte influência do ciclo PDCA na construção do ciclo. Na atual versão da biblioteca novos processos foram introduzidos a exemplo de Gestão de Portfolio de Serviços, Gestão de Eventos e Gestão de Conhecimento de Serviços (SKMS). A consolidação do ITIL v3 não está tão rápida como deveria, por vários motivos. Um deles é a complexidade da nova versão que agora possui 26 processos e 04 funções. Outro é a aplicação do curso/prova da certificação ITIL Service Manager do ITIL v2 que continua valendo (possui caminho mais curto para a certificação master). Finalmente, falta a adequação total da ISO/IEC 20000 (Certificação em IT Services Management para empresas). Esta norma está fortemente alinhada com a versão v2.

No que se refere ao ciclo de vida da gestão de serviços de TI, forneço aqui uma visão orientada a processos do ITIL v3. Poderá ajudar a entender como funciona na prática a nova versão deste framework. Estes conceitos foram extraídos de experiências, apostilas de treinamentos e do livro Introduction do ITIL v3.

No estágio inicial, o provedor de serviços de TI inicia a Estratégia de Oferta do Serviço gerenciando os requisitos de negócios (Gestão de Demandas), e traduzindo isto em uma estratégia para entregar o serviço (Estratégia do Serviço), validando os custos para manter estes serviços (Gestão Financeira) e introduzindo o serviço dentro do portfólio de serviços (Gestão de Portfolio de Serviços). Neste momento TI ainda não retorna valor para o negócio.

Quando a estratégia está completa, TI inicia a segunda fase que é o Projeto do Serviço, através de atribuição de requisitos de níveis de serviços para os serviços (Gestão de Níveis de Serviços), analisando a disponibilidade e capacidade requisitada (Gestão de Capacidade e Disponibilidade), selecionando os fornecedores que realizarão o suporte dos serviços (Gestão de Fornecedores), definindo a adequada provisão de continuidade de serviços (Gestão de Continuidade dos Serviços), validando e projetando os requisitos de segurança (Gerenciamento de Segurança) e introduzindo o serviço dentro do Catálogo de Serviços (Gestão de Catálogo de Serviços).

Na terceira fase (fase de Transição dos Serviços), o serviço está pronto para ser implementado no ambiente de produção. O provedor de serviços define o plano de transição (Planejamento de Transição e Suporte) e avalia, aprova, implementa e planeja a mudança (Processo de Gestão de Mudanças). Após a implementação da mudança, o serviço é testado (Validação e Teste de Serviço) em um ambiente de homologação. Se o teste for bem sucedido, o serviço é documentado (Gestão de Conhecimento) e seus componentes são incluídos no banco de dados de ativo e configuração (Gestão de Ativos e Configuração). A última atividade é realizar a liberação no ambiente de produção (Gestão de Liberação e Instalação) e após o “go-live”, uma revisão pós-implementação deverá ser executada (Gestão de Avaliação).

Na quarta fase (Operação do Serviço), o serviço começa a ser gerenciado e suportado para que alcance o nível de serviço acordado através do gerenciamento dos chamados dos usuários (Service Desk e Gestão de Solicitações), monitorando os alertas e eventos do serviço (Gestão de Eventos), restaurando as interrupções não programadas dos serviços (Gestão de Incidentes), evitando as causas dos incidentes e reduzindo a duração de incidentes (Gestão de Problemas), gerenciando a maneira segura de utilização do serviço (Gestão de Acesso), mantendo o produto de software (Função de Gestão de Aplicação), executando as atividades diárias (Gestão de Operação) e suportando a infra-estrutura (Gestão Técnica).

A fase de Melhoria Contínua do Serviço é acionada durante todas as fases do ciclo de vida. É responsável por medir o serviços e os processos (Medição dos Serviços), e documentar os resultados (Reporte do Serviço) para que seja melhorada a qualidade do serviço e a maturidade dos processos (Melhoria do Serviço). Estas melhorias devem ser implementadas na próxima fase do ciclo de vida do serviço, iniciando-se novamente na Estratégia do Serviço e ciclo então recomeça.

Espero ter contribuído para um entendimento mais claro do ciclo de vida de serviços. O ITIL v3 é fundamental para o sucesso da certificação ISO/IEC 20000, apesar do relacionamento mais forte desta norma com o ITIL v2. Processos novos como Gestão de Eventos, Gestão de Fornecedores, Gestão de Demandas, Gestão de Catálogo de Serviços e Gestão da Operação, não existentes de forma isolada no ITIL v2, são exigidos para compliance com a norma.