Sobre o Valor de Licenças de Software em BI

O Serpro, a empresa na qual trabalho, vive o mesmo dilema de qualquer empresa que resolva investir em SL: comprar uma licença.

Peraí. SL não é livre? Então não precisa pagar, não é?

Não tem nada a ver. SL é livre se pode ser usado, modificado e distribuído (modificado ou não) livremente. Porém, como qualquer outro produto, precisa de conhecimento para ser bem usado. E é ai que entram os custos de SL.

Eu já discorri sobre isso na apresentação feita na Fatec, então não vou me repetir. Vou apenas adicionar um pouco sobre isso no campo de BI.

Sobre licenças de software no mundo de BI: solução barata, em BI, custa um milhão de dólares. Solução boa é de cinco milhões, mas eu gostava mesmo era das de dez em diante (a proposta mais cara que eu vi era de dezessete milhões de dólares, inicial, e renovação de cinco milhões de dólares anuais.) Veja porquê.

O valor cobrado pelas suites livres (Pentaho, Spago, Jasper) é o mesmo que fornecedores "comerciais" cobram de consultoria para instalação e treinamento. Eu sei disso porque eu vendia SAS e concorria diretamente com a MicroStrategy e a Informatica. Eu nem sequer visitava o cliente se ele não pedisse proposta que desse, pelo menos, meio milhão de dólares. Pelo valor que a Pentaho cobra, eu usava só uns quinze minutos para atender o cliente, mandando uma proposta pré-formatada: preenchia os nomes do contato e da empresa, imprimia em PDF e mandava por e-mail (nem mandava por correio, que era a norma da empresa.)

Em 2009, fizemos eu e Gerson Tessler, no Serpro, uma conta rápida para mostrar uma das vantagens do Pentaho: o valor que o Serpro pagou de upgrade do MicroStrategy dava para pagar mais de cinquenta anos de licença Pentaho, com usuários ilimitados (em uma máquina modesta, claro; numa parruda dava só uns 20-30 anos.)

Outro parâmetro para comparar: em 2007, só de treinamento em MicroStrategy para a equipe na qual eu estava (e que cuidava do DW PF da RFB) gastamos R$50.000,00. Isso não é caro, é preço de mercado, praticado até mesmo pela Pentaho. Foram vários cursos, para umas quatro pessoas (fora um gratuito.)

Deu para pegar uma proporção?

O custo é sempre relativo ao retorno. Como o retorno de BI sempre é MUITO grande, licenças de BI comercial tendem a ser caras. Como a maioria das empresas ainda não descobriu como usar o verdadeiro poder do BI para aumentar sua lucratividade, a Pentaho vende a suite pelo seu maior valor de face, que é ferramenta de exploração de dados (a.k.a. relatórios.) Esse é um dos motivos pelo qual ela cobra pouco. Só para não ficar dúvidas: mesmo assim, vale a mesma coisa que as caras - e eu me refiro ao SAS e ao MicroStrategy. Se você conhece SAS e MicroStrategy, e já viu o Weka ou Pentaho Analysis, sabe do que eu estou falando.

Meus Livros Favoritos

Eu também poderia intitular o post "Porque eu Preciso de um Kindle Fire", mas achei que seria demais. ;-)

Ganhei O Andar do Bêbado, de um grande amigo físico (como eu.) As primeiras páginas já mudaram meu entendimento sobre eventos aleatórios (pegadinha: na Porta da Esperança, vale a pena mudar de porta depois de o SS abrir uma errada? Resposta: SIM!!!)

Outro que eu já havia lido nesse ramo é Freakonomics: coloca questões muito interessantes e se esforça para te fazer entender que funk não causa dano cerebral, mas sim que dano cerebral te leva a ouvir funk (o carioca, no o original - obrigado Thunder!!) (ATENÇÃO: essa imagem é uma montagem, ela é falsa!!)

Eu também estou terminando de ler Scrum and XP from the Trenches (Enterprise Software Development) e Agile Software Development Scrum.

O primeiro é um relato de guerra de um cara que implementou Scrum (e outras técnicas, como XP) na empresa em que trabalha. Muito bom! Vale por uma vida e te converte para Scrum/XP/TDD nem que você diga não, obrigado.

O segundo é o relato do nascimento e estabelecimento da metodologia Scrum. Seu objetivo não é ensinar Scrum, mas contar sobre como ele nasceu, de que idéias, de que necessidades. Ainda assim, te deixa uma boa idéia de como fazê-lo (apesar de ser melhor usar livros como Agile Project Management with Scrum.) O melhor é mesmo entender as mentes por trás da idéia. Depois de lê-lo é impossível não se jogar no chão genuflexionando-se para o Scrum como se fosse a bíblia da segunda vinda do messias...

Meu próximo livro: Wicked Problems, Righteous Solutions. Em poucas palavras, porquê o modelo cascata (waterfall) falhou. Depois eu vou buscar um mostrando porquê ele deu certo (ou provando que ele funciona.) Só para não ficar na oposição. ;-)

Fora isso, meus três mais são:

1. Não é Sorte
2. O Futuro da Administração
3. How to Measure Anything

Até mais!

Valores da Hora de Analista de BI

Não é um assunto muito ligado ao tema deste blog, mas é uma pergunta que eu ouço com frequência: quanto vale a hora de um analista de BI? Eu costumo responder que varia 1) se você é PJ ou 2) se é free-lancer (body shop). Se você é PJ e está vendendo diretamente para o cliente, entre R$100,00 e R$200,00 (de jr. a sênior.)

Se você está sendo contratado por uma empresa que vai te alocar em um projeto, eu cobraria a metade: R$50,00-R$100,00. Isso deixa para seu contratador um espaço para a margem dele.

Mas esses valores são uma mistura da minha experiência no SAS em 2000, meu sentimento sobre esse mercado e os valores, e bate-papo com alguns profissionais desse mercado. Esses números são, em inglês, um "educated guess." ;-)

Mas eis que o Ricardo Gouvêa, do blog Planeta Pentaho, achou uma notícia e fez esse comentário:

Já os salários dos desenvolvedores de data warehouse poderão ter contratos com taxas variando de 65 dólares a 85 dólares por hora. Arquitetos de data warehouse podem ganhar 160 mil dólares por ano ou 80 dólares (ou mais, dependendo da experiência) por hora em contrato.

Ele retirou essas informações do site da CIO, mas a Cetax Consultoria também achou informação semelhante no site da Info. Vale a pena conferir, mesmo sendo informação sobre o mercado norte-americano. Na pior das hipóteses você terá uma referência para negociar seu próximo contrato.

Como Montar uma IBM de Software Livre

Eu sempre acreditei que, usando SL, eu posso criar uma empresa que não fabrique nenhum produto, mas mesmo assim fature alto com soluções de TI. A idéia é bem simples, até. Por exemplo, vamos dizer que um ministério lance um edital para isso:

Precisamos de um sistema para pagar conveniados do programa X, com todos os pagamentos a partir de R$100k auditados, com interface web para o conveniado acompanhar seu processo de pagamento e/ou auditoria, para que ele possa tomar as providências necessárias. Queremos que todos esses números apareçam no Portal da Transparência automaticamente, atualizado mensalmente. Todo acesso dos conveniados e funcionários da administração pública federal devem ser controlados com criptografia.

Até ontem à noite, eu não tinha uma idéia clara de como montar essa empresa, que pudesse atender esse tipo de demanda com SL. Minha visão, para mim, sempre foi muito clara – empresa três-em-um: Centro de Dados + Software House + Soluções. Se, eventualmente, o cliente decidir usar o próprio CD ou de um terceiro, como o Serpro, a empresa poderia passar tudo para lá facilmente (eu construiria as soluções para rodar em máquinas virtuais, como uma nuvem.)

Dai, digamos que essa empresa examina sua linha de produtos de SL (todos adotados, nenhum inventado por eles) e concluem que:

• O módulo financeiro de um ERP (Compieri, digamos) pode controlar as contas do convênio.
• Um AlFresco pode manter scans da documentação.
• Um Bonita Open Solution pode executar o fluxo de auditoria.
• Um eXo Portal pode ser o link com o conveniado.
• Uma solução de BI com Pentaho pode publicar os relatórios no Portal da Transparência.

Suponha que apenas metade desses aplicativos suporta SSO com criptografia. Como resolvemos?

Assim:

• Cada SL em uso na nossa linha de produtos tem sua própria equipe de desenvolvimento.
• Enquanto o 2/3 da empresa cuida de montar a infra-estrutura (CD) e implantar a solução (Soluções) o outro 1/3 (Software House) define as funcionalidades necessárias que ainda não existem.
• Em conjunto com a comunidade, as equipes de cada um desses programas evolui o SL.
• Na última etapa da implantação, a infra-estrutura atualiza o SL para a última versão comunitária, que foi desenvolvida por essa empresa hipotética.

Na verdade, já existem empresas que fazem isso para si mesmas: usam tudo livre e quando um determinado software não tem tudo, eles pagam alguém para fazer e devolver a contribuição à comunidade. Assim eles ganham duas vezes, com o resultado e alimentando o círculo virtuoso do SL.

E existem empresas como a Pentaho e a RedHat, que também fazem isso. Só que elas dão manutenção apenas nos seus próprios softwares, e tem um foco mais ou menos estanque. Elas atendem aqui e pronto. A minha idéia é um passo adiante: vender soluções e atuar como integrador, que é uma prática habitual no mercado de automação industrial.

O truque é a equipe de desenvolvimento: usar Scrum para dar manutenção em SL, como se essa equipe não fosse da empresa, mas uma equipe da comunidade que, por acaso, podemos direcionar para onde precisarmos. Se, de repente, não há demanda interna para melhorias em um determinado produto, essa equipe pode colaborar implementando as melhorias demandadas pela comunidade.

Há um grande impecilho nisso tudo: a equipe de vendas. Imagine ter especialistas em trocentos assuntos diferentes numa mesma pessoa, capaz de examinar a necessidade do cliente e desenhar uma solução Lego com SL. Provavelmente cada equipe de venda teria um especialista em pares de assuntos (Bancos de Dados e SO, BI e ERP, Workflow e BPM etc.), com um generalista capaz de analisar a demanda do cliente e definir a estratégia de implantação.

A vantagem competitiva viria do fato de essa empresa ser especialista na integração e ser co-autora em todos esses SLs. O preço também precisa ser competitivo, claro, mas com o custo de hardware caindo e a sofisticação dos SLs aumentando, isso não deve ficar caro.

Fábrica de Software? Não mesmo!

A revolução industrial trouxe a indústria como nós a conhecemos: uma linha de produção, em geral com algum grau de automação, que produz um determinado item em grandes volumes, e o mais parecidos entre si possível.

Quando a "indústria" de software começou a nascer muitos se debruçaram sobre o processo de construir programas. Depois de algum tempo começaram a perceber que a transposição dos conceitos de engenharia civil (desenhar, planejar, construir) para a informática era muito mais uma idéia bonita do que boa arte de programação.

A compreensão de porque é difícil se projetar software veio aos poucos, mas o destilado de décadas de experimentação na construção de programas de computador pode ser sintetizado em um conceito muito simples: repetibilidade.

É simplesmente impossível desenhar um processo de criação de software, genérico e repetível, que torne o processo completamente previsível e mais, que fabrique itens diferentes um do outro a cada iteração.

O mais fascinante é que tudo isso é óbvio. A fábrica fordiana mais produtiva, azeitada e veloz gasta um bom tempo sendo alterada para produzir cópias de um novo modelo de carro. A linha de produção, a indústria, fabrica itens iguais, xerocados. Inventar um novo item ou aperfeiçoar um antigo é um processo na melhor das hipóteses histórico e na pior totalmente experimental. Não existe fábrica de projetos de, por exemplo, carros ou máquinas de lavar louça. Cada marca tem o seu modo de desenvolver, aprendido a duras penas. Um novato vai precisar cometer muitos erros e ralar muito até dominar um processo criativo.

Como então alguém pode propor uma coisa maluca como uma fábrica de software? Para começo de conversa o propósito de uma fábrica de software é produzir itens novos ou, na melhor das hipóteses, reaproveitar o que já foi desenhado - nunca fazer apenas uma cópia dos itens pré-existentes!

O contra-argumento à essa linha é a indústria da construção civil: cada novo prédio é algo inédito e o mero sucesso de um largo número de projetos indica que é possível, sim, definir um processo dessa complexidade que seja repetível.

Bom, basta observar essa indústria um pouco mais atentamente para notar que ela confirma a regra: o processo de construir um novo prédio é conhecido e repetível. Todos são estruturas calculáveis, definidas e com quantidades de materiais previsíveis. Aliado ao conhecimento histórico sobre produtividade em construção civil, hoje praticamente item de livro-texto de Engenharia Civil, gestão de projetos etc. construir um novo prédio - qualquer um, em qualquer formato! - é uma tarefa domada, não uma tarefa inédita a cada prédio.

Na minha opinião, usar Software Livre pode mudar esse jogo: evite construir cada programa de novo, mas monte coisas complexas com programas simples. Um bom exemplo são as distribuições Linux.

Case X

Como eu já comentei pelas listas da vida, eu criei e ocasionalmente ministro o curso de BI com Pentaho da 4Linux, presencial e EAD.

Entre setembro e outubro eu ministrei uma turma de Pentaho EAD. Um dos meus alunos manteve contato comigo e fomos trocando figurinhas até que ele veio a São Paulo e marcamos uma pizza. Entre outras coisas, conversamos sobre seu futuro e sua carreira em BI. Dei minha opinião sobre algumas de suas idéias, pá e tal. Isso foi em 14/11/11.

Hoje, 12/12/11, nem um mês depois, ele me liga para contar que vai abrir uma empresa de soluções de BI. Uau, isso foi rápido! Mas o mais legal é o que ele conseguiu, e como isso o motivou:

1. Ele seguiu a dica básica "trabalhe de graça e consiga um case": ele implantou uma solução de BI completa, de modelo dimensional e ETL à cubo OLAP e metamodelo em algumas semanas.
2. O resultado ficou tão bom (crédito para ele, que já tinha alguma experiência com Pentaho, e entende o que é atender bem), que o case virou cliente: devem trocar o ERP em breve, mas não vão mudar o BI, vai continuar sendo Pentaho.

Ele está finalizando a criação da empresa e prometeu-me que, quando estiver tudo assinado e pronto, me libera para eu contar os detalhes (porte da solução, nome do cliente, da empresa etc.) Por isso o nome Case X: ainda não posso contar nada.

Mudar é aprender continuamente

Quem se propõe a uma mudança de tecnologia precisa enfrentar muitos desafios, especialmente se não for o chefe da grana:

Já ouvi coisas como
"E daí? O dinheiro não é meu."
"Aprendi na faculdade usar MS. O resto que se ..."
"Sou pago para entregar o sistema. O chefe quer prazo. Uso
                                        o que aprendi na faculdade."
"Uso o que tem aqui e prepararam para mim."
"Se os grandões não estão preocupados com isso, pq eu estaria?"

Na prática, a teoria é outra.
Mudar é um processo complexo, difícil e doloroso. Mas não é inédito. Mudar é um assunto que vem sendo estudado há muito tempo. Eu gosto do tema e estou sempre procurando algo para ler e aprender (para me mudar internamente, se você percebe a idéia.)

Eis minha lista tríplice:

1. O Futuro da Administração; Gary Hamel.
2. Fearless Change; Mary Linn Manns, Linda Rising
3. Não é Sorte; Elyahu Goldratt

O primeiro é o manual de como mudar qualquer empresa, para assumir qualquer forma que se queira. O segundo é o karatê para o primeiro (eu li emprestado do Fábio Costa, meu colega de Serpro) e o último é uma ferramenta útil para resolver qualquer problema (um dos meus livros de mesa favorito.)

A quem quiser mudar o mundo, e ainda não sabe como, sugiro ler esses livros. Vai fazer você se sentir um Jedi (não é brincadeira - tem coisas que eu consigo usando o que aprendir neles que muita gente não acredita.)

-1

Hoje faleceu André Gondin. :-(

Congresso Fatec 2011 - Slides Completos

Acabo de finalizar as notas dos slides da apresentação. Você pode baixar o material a partir desses links:

• Slides (e notas) em OpenOffice
• Slides em PDF
• Notas em PDF
• Link do congresso

Aproveitando, seguem os links para os vídeos (são o mesmo, só que um é para baixar e o outro para assistir direto no YouTube:)

• YouTube
• DropBox

Re-Sourced

Quando eu descobri um cara (Marco Garcia) aqui no Brasil que ensinava Modelagem Dimensional tal como havia aprendido com o Ralph Kimball em pessoa, eu não tive dúvidas: fiz o curso com ele. Foi muito bom, e eu recomendo!

O Prof. Coruja teve a sorte de conseguir esse conhecimento diretamente da fonte! Um dia eu chego lá!