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.
Wednesday, September 5, 2012
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:
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?
"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.
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
Ao que parece, as tecnologias podem encontrar-se, em termos de ciclo de vida, numa de 5 fases distintas:
- Etapa inicial, que contempla o Trigger para a tecnologia, ou seja, o driver que leva a que a mesma surja.
- Segunda etapa, onde as expectativas inflaccionadas relativamente ao que se pode fazer com a tecnologia.
- Na terceira etapa, há uma "desilusão" ao perceber-se que afinal nem tudo dá para fazer.
- A quarta etapa traz uma nova luz sobre o que se pode realmente fazer com o que se tem.
- A etapa final já refere a utilização real e produtiva da tecnologia.
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.
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.
Subscribe to:
Posts (Atom)
