Investimentos em tecnologia

Tecnologia é geralmente vendida com base na sua capacidade intrínseca de alcançar melhorias significativas em rapidez e produtividade. Entretanto, lembre-se sempre de um dos mais famosos corolários da teoria dos sistemas: A performance do todo será sempre igual à performance do seu gargalo, seu elemento mais fraco ou menos eficiente.

Aplicar tecnologias de alta performance em sistemas lentos,  em processos mal concebidos ou não adaptativos não levará aos resultados desejados. A aplicação de mais e mais tecnologia por si só, não é uma solução, mas a criação de novas fontes de problemas.

Recentemente, em uma visita a importante organização do mercado de capitais brasileiro, verifiquei que a secretária do seu principal executivo, todas as manhãs, abria o programa de e-mail do seu chefe, imprimia as mensagens existentes na caixa de entrada e as colocava sobre a mesa do executivo, que dispendia boa parte do seu dia assinalando o que deveria ser respondido, devolvendo as mensagens com as anotações à secretária que as digitava e enviava as respostas aos interessados.

O que faz esta história ser notável é que a organização em questão, apesar de ser uma das mais informatizadas do país, demonstra uma total falta de aderência entre tecnologia, processos, cultura empresarial e retorno sobre os investimentos.

 Retorno sobre a oportunidade

Para o sucesso da implantação de qualquer tecnologia deve-se identificar claramente os processos que ela se propõe a melhorar ou substituir e analisar suas interações. Lembre-se de que o resultado fornecido por um sistema é muito mais fruto das suas interações do que dos elementos que o compõe.  É notável como os tomadores de decisão esquecem esta importante fonte primária de ganho e retorno quando se procura definir o retorno sobre um investimento com o emprego da tecnologia.

A aplicação da tecnologia da informação é feita para tornar mais ágeis, flexíveis e precisos os processos existentes em uma organização e, conduzir um projeto de informatização sem empreender esforços de melhoria nos processos é reduzir dramaticamente as possibilidades de ganho que o investimento poderá resultar.

Exemplos não faltam. Uma grande empresa de manufatura,  implantou um sistema de gerenciamento de estoques para atender objetivos de aumento do giro e melhoria da performance industrial. O projeto foi, desde o inicio, orientado pela funcionalidade do software e pouca atenção foi dada às práticas operacionais e gerenciais presentes e futuras dos armazéns e do chão de fábrica, como elas poderiam melhorar e o que deveria mudar para proporcionar tais melhorias. Resultado? Ao final da implantação a empresa tinha uma área de 4.000 m2 altamente eficiente em perder matérias primas, material em processo e produtos acabados.

Conclusão! Se os ganhos possíveis de serem obtidos com a melhoria do processo são identificados no inicio dos trabalhos, numa fase de estudo de viabilidade do projeto, a adoção de uma nova tecnologia trará resultados muito mais atrativos após sua implantação.

 Armadilhas contra o retorno

Qual a primeira coisa que vem à sua mente quando alguém menciona estudo de viabilidade? Para muitos gerentes, a tarefa de preparação de um estudo de viabilidade é focalizar os aspectos financeiros e contábeis do problema. Eles tiram o pó dos velhos livros textos de contabilidade e matemática financeira e reveem conceitos tais como: taxa interna de retorno, “payback”, valor presente e fluxo de caixa. Estes princípios são certamente importantes para uma análise completa do ROI, mas há outros passos relevantes a serem dados e que muitas vezes são esquecidos.  Em ordem de prioridade são eles:

•  Adequação às estratégias
• Identificação das ineficiências
• Adequação da tecnologia
• Viabilidade técnica e, por fim,
• Viabilidade econômica e financeira

Quando um investimento envolve a aquisição de tecnologia da informação, e isto não ocorre apenas com sistemas aplicativos, há uma tendência em manter o foco da avaliação nos aspectos técnicos e facilidades que o produto oferece. O sistema de e-mail citado no inicio deste artigo, tinha a intenção de comunicar mensagens escritas quase que em tempo real, assumindo que a organização estivesse culturalmente preparada para o uso tão óbvio deste tipo de recurso, que os procedimentos de comunicação entre as pessoas da organização eram contínuos e irrestritos e, finalmente, que o treinamento para o seu uso era desnecessário, visto que apenas o meio e não a essência da comunicação iria ser substituída. Efetivamente as premissas que se assumiram verdadeiras não eram, e os ganhos que a empresa obteve é negativo.

Vamos, rapidamente, dar uma olhada nos quatro passos acima mencionados.

Adequação às estratégias: Questões estratégicas devem ser consideradas sempre de cima para baixo, a famosa abordagem “top-down”. A alta administração é o órgão volitivo, é de lá que emanam as vontades da organização e, é ali que os objetivos são definidos. Começar pela definição do que deverá ser atingido pelo projeto nos níveis corporativo, divisional e funcional é mandatório.

É incrível como muitos projetos são alavancados por razões arbitrárias, tais como a simples implementação de mais tecnologia. Gerentes e demais membros da alta administração são constantemente bombardeados com propostas de retorno de investimento muito atrativas. Entretanto, é importante ter em mente que um modelo econômico e financeiro do ROI não responde a questão do porque fazer. Se você não sabe o motivo que justifica um projeto, o modelo usado para cálculo e apresentação do ROI não terá valor algum.

Identificação das ineficiências: A implementação de tecnologia envolve, na maioria das vezes, mudanças na forma de trabalhar e na interação entre as pessoas que executam os trabalhos. Após estar seguro de que a tecnologia está subordinada às questões estratégicas, identificar as áreas funcionais que serão afetadas e avaliar o potencial de ganho através da melhoria das formas de trabalhar é o próximo passo.

Projetos de aplicação de tecnologia de reconhecido sucesso iniciam investigando se o fazer melhor é condicionado a aplicação da tecnologia. O foco aqui é avaliar não apenas quais objetivos serão atingidos mas, também, como eles serão atingidos e como eles se relacionam com as partes da organização que serão exigidas em sua execução. É importante ter em mente que a situação apresentada pelos processos pode orientar a decisão para soluções alternativas, mais aderentes à situação em que ele se encontra naquele momento.

Adequação da tecnologia: Tecnologia deve ser estratégica e funcionalmente apropriada em relação à organização e  sua infraestrutura disponível e planejada. Os apelos dos vendedores de tecnologia em relação aos sistemas e arquiteturas abertos e protocolos que prometem interligar todos os recursos disponíveis são comuns e tentadores e, muitas vezes, induzem à falsa idéia de que não existe mais razão para preocupações com integração. Cuidado, você poderá ser conduzido a tomar decisões de investimentos futuros com base nos planos do seu fornecedor e não nos seus planos.

Viabilidade econômica e financeira: Freqüentemente os gerentes me perguntam como construir um modelo de viabilidade econômico e financeiro para o cálculo e apresentação do ROI em investimentos de tecnologia da informação. O que geralmente ouço é que o quanto se gasta é fácil identificar, mas a contrapartida do ganho é uma coisa que beira a magia ou ao esoterismo.

Em resposta, eu sempre chamo a atenção da importância de, inicialmente, ignorar aspectos da tecnologia e dar ênfase à adequação estratégica, aos objetivos funcionais almejados e às oportunidades ou necessidades de se melhorar os processos. Em seguida, um modelo econômico e financeiro deve ser elaborado apontando o que será assumido como redução de custo, agregação de valor e geração de receitas.

Há modelos prontos para o cálculo e apresentação do ROI. O que não existe são modelos prontos que identificam para você as variáveis que refletem os ganhos a considerar.  Mas este é o caminho! Primeiro porque você estará construindo um modelo completo e integro e que esgota as oportunidades de melhoria combinada com a adequação estratégica, funcional e técnica. Esta visão, como você sabe,  é muito mais aceita pela alta administração devido à sua aderência à condução que a organização quer dar aos seus negócios e não apenas aos méritos da tecnologia.

Um modelo típico de ROI identifica como uma iniciativa trará melhorias ao fluxo de caixa em um determinado horizonte de planejamento. O modelo pode aplicar uma ou mais das seguintes técnicas:

Valor Presente Liquido (VPL) é o valor nominal expresso em moeda corrente (algumas empresas utilizam US$). Ele representa o quanto de ganho ou de receita projetada excede o custo. O cálculo considera o custo de oportunidade utilizado pelas empresas. Dadas duas alternativas de investimentos e assumindo que ambas atendem aos objetivos estratégicos da organização, o investimento que apresentar o maior VPL deverá ser escolhido.

Taxa Interna de Retorno (TIR) é uma taxa de juros que aplicada sobre o ganho ao longo do tempo, anula o montante de um investimento efetuado. A TIR permite comparações entre taxas de retorno em opções de investimentos alternativas.  Dadas duas alternativas de investimentos e assumindo que ambas atendem aos objetivos estratégicos da organização, o investimento que apresentar o maior TIRdeverá ser escolhido.

Período de Payback (PPB) é o tempo total necessário para que o total das entradas monetárias de um fluxo de caixa, relativas aos ganhos, seja igual ao investimento total realizado inicialmente. Um investimento pode ser considerado pago quando o total acumulado das entradas do fluxo de caixa apresentar um valor positivo.

Finalizando

Quando você necessitar incorporar o ROI na sua proposta de aquisição de tecnologia ou ter que decidir entre alternativas de investimentos, tenha as seguintes questões em mente:

•  A iniciativa é adequada às estratégias?
• A ineficiências dos processos foram identificadas?
• A iniciativa incorpora oportunidades de melhoria dos processos?
• A tecnologia pretendida é adequada à sua arquitetura?
• O cálculo do ROI considerou ganhos e custos de forma realista?

A lei de Moore diz que a tecnologia se torna obsoleta tão logo ela é implementada. Isso é verdade quando sua aquisição é avaliada considerando-se apenas seus próprios méritos. O valor da tecnologia será preservado enquanto ela der suporte às metas de longo prazo e missão prazo da organização.

Valores exatos ou corretos, você sabe qual é a diferença?

Quando medimos desempenho de qualquer processo, podemos atribuir aos nossos indicadores valores exatos ou corretos. Os exatos mostram fatos passados, o que se quer medir deve ter sido concluído. Por exemplo: Tempo gasto para conclusão de um determinado processo. A informação obtida mostra a eficiência ou taxa de rendimento do processo que queremos gerenciar, mas ela tem caráter histórico, refere-se ao passado e, embora seja uma informação precisa, tem pouco ou nenhum valor gerencial, pois nada mais pode ser feito pelo gestor para recuperar perdas do processo e garantir as entregas, caso a informação mostre que o resultado esteja aquém do esperado.

Valores corretos, ao contrário dos exatos, mostram tendências e são apurados periodicamente, durante a execução das atividades do processo, antes da sua conclusão. Desta forma, a eficiência ou a taxa de rendimento do processo pode ser obtida e as expectativas de término podem ser informadas ao gestor para que ele tenha, caso necessário, iniciativas de recuperação de possíveis perdas ocorridas no processo.

 

De gênio e louco todo programador tem um pouco

Após anos de experiência, quando acreditava já ter visto de tudo, encontrei uma situação surreal como esta que vou contar agora.

Foi durante um trabalho de avaliação de controles internos da área de TI – Tecnologia da Informação, de uma organização do setor financeiro, cujo CIO acabara de assumir a função e, para salvaguardar suas responsabilidades, queria receber a opinião de um consultor externo e independente sobre como estava a área da qual ele seria o principal executivo.

O plano de trabalho contemplava, dentre outras tarefas, a avaliação do grau de exposição ao risco de continuidade operacional da empresa, em função da grande dependência que o negócio apresentava pela intensa utilização de recursos computacionais.

Ao conduzir o teste de conformidade para assegurar que os procedimentos ou mecanismos de desenvolvimento de sistemas estavam aderentes às exigências técnicas e práticas geralmente aceitas pela engenharia de software e de governança, encontrei programas de computador nos quais as tabelas do banco de dados tinham nomes de mulheres e as colunas das tabelas eram nomeadas com apenas uma letra.

Fiquei curioso e procurei saber o porquê do uso desta técnica inusitada, minimalista e inapropriada. Acabei por descobrir que a organização havia conduzido não muito tempo atrás, um processo de demissão e os critérios de escolha, sobre quem seria demitido não havia ficado claro. Isso levou um dos programadores de software a criar um método próprio de codificação que, segundo ele, o tornaria imprescindível, garantindo desta forma seu emprego. Pura ilusão, depois da descoberta ele que era considerado um gênio da programação pelos colegas, perdeu o emprego.

A conclusão que tirei deste episódio foi que a causa do problema não estava no processo de demissão. Afinal, as relações contratuais são efêmeras hoje em dia, tanto para quem contrata quanto para quem é contratado e às vezes inevitáveis. A real causa do problema se encontrava na falta de boas práticas recomendadas para processos de desenvolvimento de software. São elas:

1. Segregação de função – As funções de análise, projeto e programação de sistemas não devem ser executadas pelo mesmo profissional. Quando a segregação não é observada, o risco de não cumprimento dos processos e práticas estabelecidas e a possibilidade de fraude via construção maliciosa do software são incentivadas;
2. Orientação a componentes – O software é classificado como um produto de engenharia e, portanto, deve ser construído com a integração de componentes que possam ser validados tão logo sejam entregues.
3. Qualidade assegurada – Cada atividade do processo de construção de software deve assegurar a qualidade do que foi nela produzido. A certificação da conformidade do que foi produzido nas atividades anteriores garantem a qualidade em contraposição ao controle da qualidade no final do processo.

 

A profissão mais antiga do mundo

Ao ler o título deste post você deve ter tido uma ideia errada sobre qual profissão estou me referindo. Pois bem, digo a você que a profissão mais antiga do mundo é a análise de sistemas e para provar, vou contar uma pequena estória.

Três homens discutiam entre si qual deles teria a profissão mais antiga do mundo. Primeiro falou o médico e disse: A profissão mais antiga do mundo é a minha; e usando a Bíblia como referência completou, no capítulo 2 está escrito que Deus fez com que o homem caísse num sono profundo e enquanto ele dormia, tirou uma das suas costelas e criou uma mulher, isso é sem dúvida uma intervenção cirúrgica, narrada logo no início do livro, no capítulo 2 e isso prova que a medicina é a profissão mais antiga do mundo.

Em seguida falou o engenheiro: A profissão mais antiga do mundo é a minha, pois no capitulo 1 deste mesmo livro, portanto um capítulo antes daquele citado pelo médico está escrito que Deus criou o céu e a terra, uma obra de engenharia perfeita, prova de que a profissão mais antiga é a engenharia.

Finalmente falou o analista de sistemas: A profissão mais antiga do mundo é a minha. O médico e o engenheiro olharam para ele surpresos é perguntaram: Como isso é possível? Sua profissão é recente, na Bíblia não há relato que comprove o que você está falando. E o analista de sistema disse: Na abertura deste mesmo livro, portanto antes mesmo do capítulo 1, está escrito: No início nada havia exceto trevas e caos. Quem vocês pensam que criou o caos?

Pois é, já fizeram piada a nosso respeito. Mas porque será que nós analistas de sistemas ganhamos esta fama? Vou tentar explicar definindo alguns aspectos importantes da análise de sistemas.

O que é um sistema?

Sistema é um conjunto de elementos que interagem para atingir um determinado objetivo. Esta definição dada pela primeira vez por Ludwig Von Bertalanffy deixa claro que não há sistema sem um objetivo. Certo? Errado! Tenho visto muitos analistas confundirem objetivo com função daí, o sistema é construído para executar funções e não atingir um objetivo. Uma evidência clara desta confusão se dá quando você encontra várias declarações de objetivo para um único sistema. Cada sistema tem um único objetivo! Outra evidência é quando notamos que o objetivo declarado não pode ser quantificado. Os objetivos sempre devem ser quantificados, caso contrário nunca saberemos se ele está sendo atingido e qual é o nível de eficiência do sistema.

O que é escopo do sistema?

Escopo é caracterizado por um conjunto de funções contendo uma função inicial, uma função final e uma ou mais funções intermediárias. As funções iniciais e finais estabelecem as fronteiras do sistema que juntamente com as funções intermediárias definem o seu escopo.

Para identificar as funções de um sistema, o analista deve seguir um método rigoroso de investigação e esgotar todas as suas possibilidades funcionais. Nunca devemos esquecer que um sistema tem passado, presente e futuro e que suas funcionalidades podem estar associadas a estes tempos.

O que significa análise?

Analisar significa decompor o todo em partes, estudar e entender estas partes e, através do entendimento das partes, entender o funcionamento do todo. Mas como fazer a decomposição de sistemas de informação? Uma técnica simples e eficiente é decompor o sistema a ser analisado em partes denominadas contexto e a partir daí decompor os contextos em cenários, também chamados de casos de uso.

Obtidos os cenários ou casos der uso fica fácil identificar e associar as funcionalidades do escopo aos cenários ou casos de uso e estudar o comportamento destes elementos quando eles interagem para atingir seus objetivos.

Conclusão

Os resultados obtidos usando metodologia rigorosa e técnicas adequadas de análise de sistemas tem contribuído para que a função do analista de sistemas deixe de ser a mais antiga do mundo. Experimente!

Pensamento Sistêmico

Há muitos anos li um livro muito interessante chamado Introdução à Teoria dos Sistemas, escrito pelo filósofo americano contemporâneo Charles West Churchman. Logo no primeiro capítulo, o prof. Churchman faz uma provocação. Ele elabora uma lista dos problemas sociais existentes à época em que o livro foi escrito (1968) e como eles poderiam ser resolvidos com a aplicação da tecnologia. Em seguida, ele faz uma pergunta muito óbvia e simples: Se o ser humano tem a capacidade de solucionar os problemas listados com o uso da tecnologia disponível, porque não o faz? E levanta algumas questões de ordem ética e moral: Seria isso um perverso traço de caráter da condição humana? Estaríamos passando por uma fase de degradação moral que nos faz ignorar os problemas que afligem as sociedades?

Felizmente ele conclui que a causa não reside em nenhuma questão ético-moral, mas sim a uma noção de complexidade, ou melhor, uma questão de como estudar, entender e solucionar problemas complexos.

Hoje, quando o trabalho de Churchman está prestes a completar 46 anos, olhamos para as nossas organizações e vemos que o cenário não mudou. Problemas que poderiam ser resolvidos com a aplicação da tecnologia da informação, pautados pela teoria organizacional e dos sistemas, não são. O que acontece? As questões ético-morais voltaram à tona ou continuamos sem entender os problemas complexos?

Em minha opinião o fato está na forma como abordamos os problemas organizacionais. As organizações são sistemas complexos e, como tal, apresentam problemas com alto grau de interdependência e circularidade, características que levam o observador a errar na identificação da causa real do problema e conviver com situações em que o próprio efeito causado pelo problema volta à causa, atribuindo autonomia e rompendo o determinismo que o sistema poderia apresentar.

Devemos iniciar a solução de problemas pelo processo de pensamento. Se não o fizermos, poderemos enveredar por um caminho completamente errado. Churchman diz “começar a resolver um problema sem antes pensar no problema é como se um homem que estivesse perdido pegasse o primeiro caminho que visse e deixasse que os pés o levassem a certa distância antes de começar a pensar em algum modo lógico de sair da dificuldade; mas então já seria tarde demais”.

Nestas situações entra em cena o pensamento sistêmico. Ele considera a visão do todo, a composição do sistema e a interação entre seus componentes para que o todo atinja o seu objetivo. Leva em conta também um modelo estrutural que coloca o sistema dentro de um contexto determinante do seu comportamento e permite sua decomposição estrutural e funcional. Como se não bastasse, o pensamento sistêmico nos impõe restrições e premissas que definem o que é possível e viável para elaborarmos uma propostas de solução do problema.

Agora a provocação é minha: Que tal aplicar o pensamento sistêmico no seu próximo trabalho?

CIO, como você quer ser avaliado?

Descobrir ou justificar qual valor a função TI agrega aos negócios é um problema onipresente nas empresas hoje em dia. A alta administração muitas vezes ouve do seu executivo de TI o mantra: “não podemos medir o valor da TI. O benefício é intangível”. Se o argumento funciona e o CIO convence os demais executivos que seus investimentos são diferentes de outros tipos de investimentos, que exigem a quantificação dos benefícios para sua aprovação, o CIO ficará isento da responsabilidade de apresentar resultados mensuráveis e ser avaliado como os todos os outros executivos.

O tratamento diferenciado faz a prática não ser tão boa como a princípio parece. Ela causa indignação entre os executivos devido ao tratamento diferenciado na avaliação e reconhecimento dos esforços para agregar valor aos negócios. Como consequência surge entre os executivos de negócio afirmações tais como: “A área de TI é grande consumidora de recursos, mas os resultados apresentados nunca são os desejados pela organização” ou ainda, “prazos não atendidos e dificuldades para atender o que é necessário faz da TI um elemento complicador no atendimento dos objetivos”.

Para as organizações que apresentam cenários semelhantes, tenho duas observações a fazer:

a) O benefício proporcionado pela TI pode sim ser quantificado, existem métodos que o permitem fazê-lo.

b) O CIO sempre é avaliado e, sendo assim, é preferível ser avaliado formalmente e por critérios conhecidos e não com argumentos ocasionais, situacionais e até emocionais.

Pense nisso!

Programa de incentivo para o software brasileiro

O programa TI Maior, lançado em agosto último, pelo ministério da Ciência, Tecnologia e Inovação, prevê um investimento de R$ 500 milhões até 2015, valor que incluirá subvenção econômica da Financiadora de Estudos e Projetos (Finep), bolsas de estudo, investimentos em qualificação profissional e renúncia fiscal para estimular a produção e as exportações no setor de software. O objetivo do programa é incentivar o desenvolvimento de software no país para 15 setores considerados prioritários na política de inovação: educação, defesa e segurança, saúde, petróleo e gás, energia, aeronáutico e aeroespacial, grandes eventos esportivos, agricultura, finanças, telecomunicações, mineração, computação em nuvem, mobilidade, internet, jogos e computação avançada de alto desempenho. O programa objetiva também, diminuir o deficit de US$ 3 bilhões apresentado na balança comercial no ano passado.

Esta é a primeira política específica para a indústria nacional de software e serviços de TI e demonstra que o setor vem alcançando níveis mais elevados de maturidade e participação crescente na formação do PIB. Entretanto, o novo estágio de amadurecimento, exige compromissos com qualidade e busca constante da eficiência do processo produtivo. Neste aspecto chamo a atenção para a necessidade urgente  das empresas desenvolvedoras de software e tratá-lo como um produto de engenharia, elaborado por processos adequados de uma fábrica de software.

Valor da TI – Isto existe?

No mundo econômico, transações são trocas realizadas entre duas ou mais partes envolvidas num negócio. Transacionar envolve custo, e o conceito de custo de transação não é novo, ele foi desenvolvido por Ronald Coase em 1931 e, sessenta anos depois, em 1991, lhe rendeu o prêmio Nobel de economia.

Ai está mais uma oportunidade para demonstrar como a TI pode alinhar-se aos negócios. Aplicar a tecnologia da informação direcionada à teoria dos custos, dos rendimentos e da produção, todos elementos do artigo de Coase, é uma forma de usar TI no que importa.

Pense nisto!

Conhecimento ou habilidade. Qual é a sua?

As empresas estão dando mais valor à experiência do que ao conhecimento? Uma diferença fundamental entre os dois grupos é que os profissionais com conhecimento podem criar soluções independentes de paradigmas, ferramentas e técnicas predominantes. No cenário atual há dois tipos de empresas contratantes: Aquelas que valorizam o potencial do candidato e as que valorizam a experiência. O primeiro tipo investe no desenvolvimento profissional e cria oportunidades para reter o conhecimento. O outro tipo procura tirar proveito de uma experiência já adquirida e não incentiva o desenvolvimento profissional.

O que você prefere? Ser um profissional do conhecimento ou apenas um profissional hábil. Afinal, todos os especialistas e consultores de RH dizem que vivemos na época do conhecimento.

A Origem dos Conflitos

Não sei se todos vão concordar, mas está cada vez mais difícil justificar investimentos para a área de TI. O embate entre CIOs – Chief Information Officer e CFOs – Chief Financial Officer são eternos e existe uma grande dificuldade para lidar com os executivos que não estão ligados diretamente a TI dentro das organizações.

Muitas vezes, justificar um projeto para esses profissionais tende a ser um desafio. Em especial, devido à área de TI ser considerada um centro de custos pela maior parte das organizações.

No caso específico do CFO, o conflito dele com o CIO tem origem, na maior
parte dos casos, na comunicação. Isso porque, quando o executivo de TI senta à mesa de discussão para aprovar um projeto com a área financeira, ele fala de equipamentos e serviços, mas esquece de que a única coisa que interessa ao executivo financeiro é quanto a iniciativa vai custar.

A seguir, alguns cuidados que o CIO deve tomar na hora de conversar com o CFO e minimizar os conflitos:

1 – TCO e não ROI

O pensamento tradicional de ROI – Retorno Sobre Investimento não costuma funcionar quando o projeto não tem indicações claras de retorno. Para o CFO, esse termo significa quanto dinheiro a área de TI vai trazer para a companhia com o investimento. E, a maioria das iniciativas de TI não traz retorno direto para a organização como o obtido com iniciativas tais como: novas campanhas de marketing ou o lançamento de produtos.

Portanto, o recomendável é discutir com o CFO o custo total de propriedade (TCO) que pode ser utilizado para demonstrar que uma determinada solução reduzirá custos. Mas, para isso, é necessário oferecer opções, comparações, estudos de caso e exemplos práticos.

2 – Projetos

CFOs precisam ouvir que determinadas tecnologias e processos podem economizar custos. Use este argumento direcionando as expectativas dele para os projetos certos de TI. Qualquer executivo da área de finanças entende, por exemplo, que não se deve guardar dados de clientes ou informações financeiras sensíveis em ambientes abertos e colaborativos.

3- Economia

De tudo o que se fala sobre SOA, TI verde, virtualização, orientação a objetos, dentre outras técnicas, práticas e paradigmas não vai estimular o CFO. Para ele, os projetos só existirão se eles melhorarem o TCO. De novo, é importante construir um discurso baseado em fatos concretos e que tenha como base questões como o quanto a tecnologia pode reduzir custos. O desafio é fornecer estimativas concretas de economia.

4 – Risco

A continuidade dos negócios é um fortíssimo argumento.  Gestão de risco, recuperação de desastres e continuidade de negócios não têm merecido a devida atenção das empresas pelo fato de ficarem concentradas na área de TI, sem a participação dos demais gestores das empresas. Mude esta situação. A transformação começa pela adoção de um plano para continuidade dos negócios, coordenado pela área de TI com o envolvimento das áreas de negócios, que ajudarão nas questões mais críticas e quais as prioridades devem ser consideradas após a ocorrência de um desastre. A participação dos executivos externos a TI no processo de decisão sobre os riscos diminui, quando não elimina o abismo existente entre eles e a área de TI.

5 – Objetivos

Não deveria ser mais necessário dizer que os projetos de TI devem estar alinhados com os objetivos da organização. Contudo, grande parte das iniciativas não é e, portanto, a área de TI tem de melhorar esta situação. Para alinhar a tecnologia com as metas de negócio há a necessidade de entender como a TI pode ser um diferencial para a entrega de produtos e serviços e como ela agrega valor (IT Value).

6 – Custos

Estudos detalhados sobre a organização levam o CIO a descobrir oportunidades de redução de custos com pequenas iniciativas. Um dos principais vilões na composição dos custos é o retrabalho. Apenas para citar alguns: falta de reutilização de componentes, planejamento inadequado dos projetos e operações, identificação e definição precária dos KPIs, falta de critérios para a terceirização de algumas atividades, processos informais de trabalho e de gerenciamento.

Pense nisso!