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.

Desafios em contratos de outsourcing de TI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Risk Governance

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

2. Risk Evaluation

• Coleta dados
• Analisar os riscos
• Manter um perfil dos riscos.

3. Risk Response

• Articular os Riscos
• Gerenciar os Riscos
• Reagir aos Eventos

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

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

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




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