quarta-feira, 11 de maio de 2011

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

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.

domingo, 16 de janeiro de 2011

Uma Abordagem de Lean Six Sigma em TI

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.

domingo, 17 de outubro de 2010

Um Insight em Gestão de Riscos de TI

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.

domingo, 29 de agosto de 2010

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

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

sexta-feira, 9 de julho de 2010

Uma Perspectiva de Ecossistema para PD&I

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.

sábado, 29 de maio de 2010

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

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 ...

domingo, 25 de abril de 2010

O que importa no atendimento de serviços de TI

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.

domingo, 31 de janeiro de 2010

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

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.

sábado, 26 de dezembro de 2009

Conceitos de Segurança e Auditoria de Software

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.

sábado, 21 de novembro de 2009

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

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.

sábado, 3 de outubro de 2009

De onde vem os inovadores? (Parte 2)

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.

domingo, 23 de agosto de 2009

De onde vem os inovadores? (Parte 1)

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.