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.

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.

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.

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.

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

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

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

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

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

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

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

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

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 ?

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.