Mostrando postagens com marcador bi. Mostrar todas as postagens
Mostrando postagens com marcador bi. Mostrar todas as postagens

quarta-feira, 9 de janeiro de 2013

Escravocratas do Século 21


Comecei a minha carreira profissional de TI como muitas pessoas da minha idade no final da década de 90: fazendo sites. Em bem pouco tempo isso se tornou um profissão de verdade: Desenvolvedor Web, ou coisa que o valha. Hoje esse profissional pode ser chamado por muitos nomes, mas continua requisitado.

Passei por empresas "pontocom" na época da bolha, e a vi estourar. Apesar de catastrófico, foi um momento interessante pra se viver, pois compreendi muitos termos e seus significados reais como empreendedorismo, plano de negócios, investidor anjo, venture capital e vários outros que ferviam na web daquela época. Entendi também o que faz e o que não faz sentido dentro de uma empresa quando o objetivo real dela é dar lucro.

Por causa da recessão que atacou esse tipo de empresa, acabei participando de processos seletivos para trabalhar em empresas "normais" que na época eram chamadas de "bricks and mortar", ou seja, as empresas de verdade na visão dos que já desacreditaram da internet como uma via real para fazer negócios verdadeiramente lucrativos.

Por indicação de um amigo, fiz uma entrevista em uma empresa de consultoria de TI, e na época, em 2003, eu não sabia o que isso significava. Nunca tinha tido contato com o conceito de consultoria na prática, mas gostaram de mim e fui contratado. Meu background era o conhecimento das linguagens de programação para web que existiam na época e eu já tinha uma certificação de DBA Oracle 8 que estudei muito para conseguir e paguei do meu bolso, o que me faz pensar agora como estou velho, mas esse não é o ponto.

Quando me dei conta, estava trabalhando em uma consultoria que tinha clientes bem significativos no contexto corporativo do Brasil e comecei a entender o que era ser consultor e como esse mercado funcionava. Ser consultor era não saber muito bem onde eu estaria na semana seguinte, porque poderia ser necessário estar em outra cidade ou estado para atender alguma demanda. Era ter que ficar com o celular ligado 24/7 em caso de alguma emergência. Era aprender sobre o negócio do cliente mesmo sem nunca ter assistido a uma única aula de faculdade sobre aquele assunto. Era bem mais do que isso, mas não vou descrever o que é ser consultor, só que eu já estava me divertindo bastante e a vida profissional de consultor de TI já tinha me conquistado. Eu queria mesmo continuar fazendo aquilo.

Havia uma peculiaridade nisso tudo, eu era consultor de um negócio chamado Hyperion, que nem meus professores de faculdade conheciam, menos ainda meus colegas e profissionais de outras empresas. Parecia uma tecnologia meio que à margem de tudo o que estava acontecendo e fervilhando na internet e na tecnologia de maneira geral. Enquanto muita gente queria certificações Java, eu estava me tornando especialista em uma coisa que ninguém, ou quase ninguém sabia o que era. Isso poderia ser ótimo ou péssimo. Ou eu teria um conhecimento raro e por consequência desnecessário e sem valor ou eu teria um conhecimento raro e por consequência necessário e caro. Pra minha felicidade, a segunda opção se tornou realidade. A quantidade de projetos Hyperion aumentou muito se compararmos 2003 com 2013 e o mercado mundial não consegue atender totalmente a demanda por esse tipo de profissional que pode cobrar taxas bem altas em alguns lugares do mundo, por exemplo, um profissional experiente em Hyperion Financial Management pode cobrar uma taxa de até 500 libras esterlinas por dia em Londres.

Obviamente quando o mercado viu esse movimento acontecendo, muitas consultorias começaram a oferecer serviços e projetos Hyperion e para atendê-los foi necessário procurar esses profissionais no mercado e pagá-los a peso de ouro. Mas com isso surgiram alguns problemas. Um deles foi o fato de que surgiram consultorias novas e pequenas. E talvez você diga que isso é bom e eu acho realmente que deveria ser, afinal eu sou completamente a favor do empreendedorismo e da fomentação de novos negócios. Seria bom se todas essas novas consultorias fossem capazes, competentes e principalmente éticas.

Com o aumento da competição, empresários e gestores sem muitos escrúpulos contratam consultores no mercado, muitas vezes com salários altos, eventualmente até bem acima dos valores praticados pela maioria das consultorias e fazem isso para demonstrar aos seus clientes reais ou em potencial, que tem um time de consultores capaz de implementar projetos Hyperion ou para atender à algum projeto que já foi vendido mesmo sem que a consultoria tivesse um time para implementá-lo. O resultado disso é a venda de projetos com prazos ditados pelo cliente, e não estimados por profissionais capacitados.

Vou dar um exemplo: a área comercial da consultoria tenta vender um projeto de 3 mil horas, o cliente reclama, diz que é muito caro, ameaça não fechar negócio, pressiona, insiste, faz leilão entre os fornecedores com a velha estratégia "mas aquele fornecedor faz por menos" e então o fornecedor que conseguir achatar mais o projeto fazendo com que o projeto fique com menos horas, menos recursos e por consequência com o menor preço, leva o contrato.

Depois do projeto vendido, o vendedor sai de cena, a área comercial já fez a parte dela e agora é com a equipe de delivery. Aqueles que vão implementar o projeto que se responsabilizem por entregar no prazo e sem espremer a margem, lógico. Se o projeto de mil horas foi vendido, a equipe de delivery deve fazer o possível e o impossível para entregá-lo em 800 horas, de preferência, não importa que o projeto deveria ter sido vendido com 3 mil horas, porque agora já foi vendido. Você é parte do time do projeto? Então é responsabilidade sua entregá-lo com qualidade e no prazo, independente da incapacidade do vendedor perceber se aquilo que ele vendeu faz sentido ou não.

Esse não é um cenário caricato, eu passei por ele algumas vezes e na última vez que isso aconteceu foi bastante traumático pra mim. Eu perdi o sono e a tranquilidade, porque a consultoria não me apoiou em nada e era eu que tinha que me explicar com o cliente, não o vendedor que fechou o negócio nem o executivo que cobrava os meus resultados. Ao contrário, fui ameaçado de algumas formas pelo meu empregador durante o projeto e também no momento que decidi sair da empresa. Me foi dito que "o mercado é pequeno e eu deveria cuidar para que as minhas decisões não me prejudicassem".

Esse tipo de padrão só vai continuar acontecendo se os profissionais não se sujeitarem a esse tipo de situação. Eu saí do projeto e da empresa, não podia sacrificar a minha tranquilidade, a minha capacidade profissional e nem a minha ética diante do cliente. Eu recomendo que você faça o mesmo se estiver passando por situação semelhante, tome atitude, converse com quem você acredita que pode te ajudar de alguma forma, seja com seu gestor, com seu gerente de projetos, com seu RH, enfim, não aceite esse tipo de situação passivamente pois dessa forma você estará colaborando para que o mercado não valorize o trabalho dos seus colegas, o seu trabalho e principalmente o maior bem que você consultor tem: o seu conhecimento. Esse ativo você lutou para conseguir e ninguém tira de você, portanto valorize tanto quanto puder mantendo a ética e a boa fé em qualquer situação. Não haverá arrependimento nisso.

Se eu puder dar dicas sobre como evitar problemas com os "escravocratas do século 21" (obrigado ao meu amigo Carlos Freitas pelo termo genialmente cunhado) diria que você deveria:


  • Procurar conhecer o histórico da consultoria no mercado antes de assinar um contrato de trabalho com ela.
  • Verificar se ela já possui contratos para você trabalhar ou se ela quer te contratar para poder conseguir contratos. A segunda opção pode ser uma boa possibilidade desde que você tenha ciência disso, assuma os riscos e negocie bem a recompensa em caso de sucesso.
  • Conversar com pessoas que já trabalham ou trabalharam na empresa e tentar coletar informações relevantes como: clima entre profissionais, relacionamento dos profissionais com os executivos, estratégias comerciais, oportunidades de crescimento, entre outras que você julgar relevante para a sua carreira. O LinkedIn está aí pra isso também, use sem medo.

 
Na era da informação, faça ela trabalhar a seu favor. Informação demais, nesse caso, nunca vai fazer mal.

Sucesso nos seus projetos em 2013!

sexta-feira, 27 de agosto de 2010

A TI do novo Brasil e CPM Braxis

Para os que não sabem, atualmente trabalho como consultor de Business Intelligence e Enterprise Performance Management na CPM Braxis, a maior empresa de serviços de TI do Brasil e recentemente contribuí na produção de um artigo chamado A TI do novo Brasil que pode ser lido no site da CPM Braxis.

Juntamente com Nicola Mazzi (do blog BI & Cia) e Gustavo Monteiro, ambos executivos de serviços da CPM Braxis, falamos sobre vários aspectos do Business Intelligence e Enterprise Performance Management, mais especificamente sobre "Tecnologia e Conhecimento de Negócios para a Excelência na Tomada de Decisão".

O artigo está aqui em PDF.

quinta-feira, 11 de fevereiro de 2010

Otimização de Aplicações Planning Pré-existentes – Parte 1

Uma pergunta comum dos clientes que já tem aplicações Planning pré-existentes é "como posso otimizar a performance das minhas aplicações?". Duas iniciativas simples que eventualmente podem ajudar na melhora da performance para ambientes Planning já estabelecidos são:
  1. Remover dados históricos desnecessários
  2. Reorganizar os outlines
Remover dados históricos desnecessários

É comum que se mantenha todo o histórico de dados em aplicações Planning para facilitar a análise ano a ano. Manter uma quantidade excessiva de dados históricos no Planning significa ter uma quantidade enorme de blocos desnecessários e quanto maior a quantidade de blocos, maior o tempo de processamento dos cálculos. É claro que geralmente é necessário  manter os dados históricos disponíveis de alguma forma para análise ao longo dos anos e para isso recomendo a prática de criar aplicações Essbase para reporting de dados históricos facilitando assim a otimização das aplicações Planning. Cubos Essbase para reporting podem ser desenvolvidos para manter dados históricos. Esses novos cubos Essbase devem ser desenvolvidos baseados nas aplicações Planning mantendo a mesma estrutura. Todos os dados que não sejam para novos planejamentos orçamentários ou forecasts devem ser movidos para esses cubos de reporting que são "puramente" Essbase. Essa integração entre as aplicações Planning e os cubos Essbase de reporting podem ser feitas usando técnicas como Partitioning, @XREF, ou mesmo exportação e importaçao de dados (export/import, report scripts). Os dados de planejamento como Orçado, Forecast, etc, permanecem nas aplicações Planning e através de processos de automação, ao longo dos anos os dados que se tornam históricos são migrados para as aplicações Essbase de reporting. Sugestão de passo a passo para migrar os dados históricos do Planning:
  1. Crie aplicações Essbase nativas para receber os dados históricos.
  2. Os novos cubos devem ser baseados na estrutura das aplicações Planning existentes.
  3. Remova das aplicações Planning todos os dados que não tem relação com o processo de geração de novos budgets e forecasts.
  4. Carregue os dados históricos nas aplicações nativas Essbase para reporting.
  5. Remova os membros das dimensões do Planning que dizem respeito apenas aos dados históricos.
  6. Escolha uma das técnicas disponíveis e integre os dados do ano corrente do Planning com os cubos Essbase de reporting.

Reorganizar Outlines

Pela "cartilha" ou se preferir "by the book" é sabido que a organização de outlines deve ser feita de cima para baixo:
  1. Dimensões densas com a maior quantidade de membros stored até as dimensões densas com a menor quantidade de membros stored
  2. Dimensões esparsas com a menor quantidade de membros stored até as dimensões esparsas com a maior quantidade de membros stored.
É claro que essa regra não se aplica a todos os modelos mas é recomendado que se comece dessa forma executando várias fases de testes com múltiplas configurações executandos os cálculos em cada uma delas até chegar na organização ótima do outline.

É possível também simular cálculos usando SET MSG ONLY no calc script. Um cálculo simulado oferece resultados que ajudam na análise da performance de um cálculo real baseado nos mesmos dados e no mesmo outline

Executando um cálculo simulado com um comando como o SET NOTICE HIGH, é possível verificar o tempo de cálculo de cada dimensão esparsa. Depois, executando o cálculo real em uma ou mais dimensões é possível estimar quanto tempo o cálculo vai demorar pois deve ser alguma coisa bem próxima do tempo do cálculo simulado.

Obviamente não considere esses passos como sendo o ciclo completo de otimização das aplicações Planning, considere como um bom começo.

quinta-feira, 26 de fevereiro de 2009

Do you speak Hyperion?

Coisa rara é encontrar material de boa qualidade, em português, sobre ferramentas específicas de BI. Pelo menos sobre as ferramentas que eu estou acostumado a trabalhar.

Hyperion nunca foi um nome pop entre os profissionais de TI, pelo menos não antes da Oracle adquirir a empresa, mas sempre foi um nome de muito peso na sua área de atuação. Os profissionais qualificados nas ferramentas Hyperion são escassos no Brasil e pelo jeito, no mundo todo, pois nos países emergentes e nos países desenvolvidos, profissionais desse tipo tem sido contratados a peso de ouro. Só não sei por quanto tempo.

Trabalho com Hyperion Essbase desde 2003 e percebo que todos os profissionais que acabam caindo nessa área tem dificuldade de encontrar recursos e informações claras à respeito de Essbase além do Database Administrator Guide. Sim, o DBAG é um ótimo recurso técnico, mas não documenta muitas boas práticas importantíssimas para o desenvolvimento de um bom projeto de aplicações OLAP em Essbase. É bem verdade que é preciso "comer muito feijão" para compreender profundamente uma modelagem multidimensional e propor mudanças conceituais ou, mais complexo ainda, compreender do negócio do cliente e propor um modelo multidimensional eficiente, coisa que está muito antes da escolha da ferramenta.

A verdade é que eu percebo um certo receio dos profissionais Hyperion quanto à expor informações técnicas relevantes. Isso não é uma crítica, é uma constatação. Parece que alguns pensam que seu emprego está em risco se mais pessoas conhecerem a tecnologia.

Eu, particularmente, não penso assim. Toda tecnologia de qualidade tende a ser absorvida pelo mercado como aconteceu com Java, Oracle, PHP, etc, portanto, é questão de tempo até que o conhecimento sobre Hyperion, BI, OLAP, etc, esteja completamente pulverizado e mão de obra de baixa qualidade comece a pipocar por aí. Como acontece com qualquer tecnologia, existirão dois grandes grupos de profissionais:

1. Profissionais de alto nível, competentes, bem posicionados e bem remunerados.
2. E existirá uma nuvem de gente que talvez compre um livro "aprenda seiláoquê em 24 horas" porque acha que isso dá dinheiro.

Eu não me preocupo com nenhum desses grupos. Os primeiros são grandes ajudadores, são pessoas em quem os profissionais devem se espelhar quando tiverem a oportunidade de trabalhar com eles. O segundo grupo nunca incomodou os profissionais competentes que sempre vão ter espaço no mercado. Com isso quero dizer que o que motiva esse blog é a minha vontade de melhorar o meu próprio trabalho. Quero dizer que o blog ajuda a mim mesmo, a reler como realizo algumas coisas no meu trabalho. Ajuda a perceber que "faz sentido" se uma outra pessoa lê e entende o que eu procurei fazer. E espero que acabe ajudando alguém que passe por aqui procurando alguma coisa útil.

Se for útil para você também, ótimo. Qualquer dia desses tomamos um café em algum projeto por aí...