Wednesday, September 5, 2012

ROI de Projetos de SI. Calcular é mais fácil do que parece!

Quantas vezes ouvimos em reuniões ou lemos em diversos artigos que é necessário alinhar a tecnologia e o negócio, sendo apontado como um dos aspetos importantes o cálculo do ROI - Return On Investment - do projeto? Quantas vezes a Administração da empresa pede à Direção de Sistemas de Informação (SI) para que apresente uma estimativa de ROI dos projetos a lançar ou dos projetos realizados e em curso? E, sem isso, não aprova o lançamento dos novos projetos!
Este é um desafio cada vez mais normal de ser lançado no mercado de SI, mas são poucos os casos que tenho visto realmente comuns a fazer de forma rotineira. Porquê?
Há muitas razões certamente, mas há uma que tenho identificado como constante e que é: as equipas de SI não sabem como se faz um ROI de um projeto! Noutros casos, os SI estão habituados a serem meros  executantes e desconhecem o que o projeto faz em termos de negócio. Várias vezes oiço "Não sei para que é que aquilo serve. Disseram-me para fazer isto!". E noutros casos ainda, mesmo sabendo o que faz o projeto em termos de negócio, há a dificuldade da equipa de SI em explicitar quais são as variáveis que podem fazer sentido para avaliar o retorno.
Isto já lhe aconteceu? Em tempos também já passei por isso. Quando saí do IST como Engenheiro Informático ensinaram-me a especificar, criar arquiteturas, programar, etc, mas nada de Gestão de SI.  Mas é mais fácil do que parece. De uma forma simplificada, o ROI tem por base dois caminhos de avaliação, que podem inclusivamente ser simultâneos:  a avaliação com base na geração de mais negócio/receita e/ou otimização de processos existentes. Assim, os passos base têm sempre como comparação a situação conhecida, isto é, é comum definir como base comparativa a situação atual, o "nada fazer" e/ou comparar vários cenários alternativos.
O cálculo do ROI começa sempre pela identificação das variáveis em jogo no projeto, que na geração de novo negócio tem associado, normalmente, potenciais de receita vs investimentos feitos. No caso de otimização de processos há, normalmente, uma variável sempre existente - "Tempo". Como se costuma dizer: tempo é dinheiro e é isso mesmo!
Por exemplo, se a implementação de um projeto me reduz em 50% o tempo de um processo, a técnica é quantificar em dinheiro esse tempo. Se uma pessoa demora a realizar uma tarefa 20 horas e com o novo projeto demora 10 horas, isso é dinheiro no final do mês, pois aumenta-se a produtividade da organização.  Se, por outro lado, do projeto há a geração de receitas oriundas do novo produto ou serviço, essa é também uma variável em jogo. A verdadeira questão é: “Quanto dinheiro traz o novo projeto à empresa?”.
E, assim, depois de se identificarem as diferentes variáveis e as suas dependências, tem-se as condições base  para estruturar o modelo de negócio de cálculo do ROI. Há que separar todos os custos de investimento, dos custos de manutenção (todos! há vários "escondidos"), e definir tempo de vida do produto ou serviço subjacente ao projeto. Tipicamente na informática o normal de um ciclo de vida de um produto ou solução são os 4 ou 5 anos, contudo esta é uma variável específica que depende também do mercado onde se encontra a empresa.
O segredo é, comparar um ou mais cenários com o cenário base (normalmente a situação existente) e está identificado o comparativo de ROIs. Com estes dados,  pode-se identificar outros indicadores de projeto como o VAL - Valor Atual Liquido, Margens operacionais, Free Cash Flows, o Custo de Oportunidade de lançamento do projeto, etc.
Aspeto adicional é o de ao longo da execução do projeto escolhido se ir analisando e comparando com o cenário previsto calculado, de forma a conferir a estimativa com a realidade do ocorrido. Este procedimento permite assim a  avaliação do comprometimento estabelecido inicialmente e a aprendizagem do processo de avaliação de ROI para futuros projetos.
Em jeito de conclusão, o aumentar da importância estratégica dos SI está também na sua forma de gestão financeira e nas justificações perante a empresa da sua capacidade de potenciar negócio, demonstrando-o! Os profissionais de SI têm e devem, por isso mesmo, ter cada vez mais conhecimentos de economia e gestão, saindo das suas normais áreas de conforto de "Bits e bytes" e dos "If-then-else". O compreender o negócio é essencial para se poder dar a melhor solução e valor acrescentado. Se nós, os "informáticos", não o fizermos, os SI continuarão a ser vistos como uma continua Atividade de Suporte das empresas e não como uma Atividade Estratégica.

Monday, August 27, 2012

Glaciares de Dados

O trocadilho, embora admita que não seja o mais feliz, espelha o mais recente anúncio da Amazon: o Glacier. Numa definição dada pela própria Amazon:

"Amazon Glacier is an extremely low-cost storage service that provides secure and durable storage for data archiving and backup. In order to keep costs low, Amazon Glacier is optimized for data that is infrequently accessed and for which retrieval times of several hours are suitable. With Amazon Glacier, customers can reliably store large or small amounts of data for as little as $0.01 per gigabyte per month, a significant savings compared to on-premises solutions."

O Storage foi considerado até agora, e na maioria dos casos, para um de dois propósitos:
  • Armazenamento per se - utilização de espaço de armazenamento para isso mesmo, por vezes com aplicações que permitem a gestão do espaço a partir de uma UI.
  • Armazenamento aplicacional - dados como parte integrante de uma aplicação de negócio.
Com a introdução de um serviço como o Glacier, as coisas mudam um pouco. Passamos a ter não apenas Storage, mas sim um storage "gelado", com dados que não são acedidos com muita frequência e que por isso mesmo permitem níveis de serviço radicalmente diferentes dos dados normais. Neste caso, os dados nem sequer estão sempre acessíveis, sendo necessário criar jobs específicos para o efeito, que depois ficam disponíveis durante 24 horas. O conceito é interessante, e para empresas que mantenham um histórico que não precisam de aceder muitas vezes, pode ser vantajoso em termos económicos, sendo que à data deste post não tive ainda oportunidade de comparar o preço do serviço com a alternativa AWS ou mesmo a de outros providers.

Este tipo de serviço faz lembrar alguns filmes, como é o caso do "Demolition Man", em que o Stallone fica em preservação criogénica para ser recuperado apenas mais tarde, quando fizesse falta. Na prática, preservamos algo até que nos faça falta, e quando fizer limitamo-nos a aceder.

Até ao momento não tenho conhecimento de alternativas semelhantes dos outros cloud providers. Estou curioso para ver como os restantes players vão reagir, mas esta notícia é prova que os cenários de cloud e as soluções e serviços a fornecer são ainda muitos, e em cenários aparentemente semelhantes ao que existe, tecnológicamente, mas com casos de uso bem diferentes. E é isso que torna o cloud computing num dos temas mais interessantes da actualidade.

E, agora que me lembro, alguém sabe para que serviam as três conchas?

Friday, August 17, 2012

Os termos mais "Hype" da Cloud

Confesso que não fazia ideia de que a Gartner avaliava o quão Hype são as tecnologias, por isso foi com alguma surpresa que recebi o seguinte artigo: Gartner: Cloud computing's most over-hyped terms.

Ao que parece, as tecnologias podem encontrar-se, em termos de ciclo de vida, numa de 5 fases distintas:
  1. Etapa inicial, que contempla o Trigger para a tecnologia, ou seja, o driver que leva a que a mesma surja.
  2. Segunda etapa, onde as expectativas inflaccionadas relativamente ao que se pode fazer com a tecnologia.
  3. Na terceira etapa, há uma "desilusão" ao perceber-se que afinal nem tudo dá para fazer.
  4. A quarta etapa traz uma nova luz sobre o que se pode realmente fazer com o que se tem.
  5. A etapa final já refere a utilização real e produtiva da tecnologia.
Vendo o processo de uma forma tão "crua", quase que faz lembrar alguém numa saída à noite antes de ir falar com a mulher mais bonita da sala. E no final, acaba por sair com a amiga simpática que lhe deu conversa depois da tampa inicial! :)

Piadas à parte, a conclusão do estudo é de que no geral o Cloud Computing já passou a fase das grandes expectativas, mas existem ainda alguns aspectos cujo Hype se encontra extremamente inflaccionado.


O tema da Big Data é uma das vertentes mais próximas do topo das expectativas altas. Com várias iniciativas e empresas a proporem cada vez mais soluções e serviços, o mais provável de acontecer é que os potenciais benefícios que se podem tirar façam com que se passe rapidamente pela desilução e se comecem a implementar grandes projectos, fruto das vantages que daí se podem obter.


PaaS é um termo familiar para qualquer empresa ou pessoa que esteja minimamente informada sobre a Cloud. Grandes empresas como a Microsoft, IBM, Oracle e a já referida Red Hat estão a apostar na Cloud e no PaaS e esta orientação só vai aumentar. PaaS consiste em ter uma "pedaço de núvem" onde podemos alojar as aplicações preocupando-nos apenas com as mesmas e não com sistemas operativos ou componentes de infra-estrutura.


O Cloud Storage foi um dos temas mais focados ao longo de todo este tempo. No entanto, foi um dos que mais críticas levou também, fruto de alguns problemas que ocorreram num passado recente com alguns dos maiores fornecedores como a Amazon e o Salesforce.com. A Gartner recomenda a utilização de Cloud pública para aplicações não críticas enquanto não estiverem reunidas as condições legais e de segurança necessárias.


Além dos temas referidos, o artigo refere algumas tendências interessantes de que ainda não falei.

Community Cloud - Na prática, juntar economias de escala a economias de cloud. Clouds partilhadas entre empresas para tirar partido de melhores condições financeiras.

Cloudbursting - Tirar partido da elasticidade da Cloud em cenários de carga que o justifiquem. Actualmente já é possível fazê-lo mas maioritariamente de forma manual. A Gartner prevê que esta seja uma tendência em breve, mas a tecnologia ainda tem de amadurecer. Estamos a falar de transição de workloads entre fornecedores cloud diferentes, e para isso é necessária a criação de standards de modo a garantir a portabilidade.