O Que Leva à Alta Performance?

Michael Porter, da Harvards Business School, diz que o rendimento de uma empresa é empurrado por dois fatores: estratégia e execução.

Phil Rosenzweig escreveu em seu livro The Halo Effect (com a tradução Derrubando Mitos) que, se isso é verdade, então tocar uma empresa com sucesso é uma coisa arriscada pelo simples fato de que nada dá a menor garantia que escolheremos sempre a estratégia vencedora, ao invés de alguma outra estratégia furada.

Não bastasse a dificuldade na escolha da estratégia, a execução dela também é um desafio de porte semelhante. Coisas que funcioaram para uma empresa não necessariamente vão funcionar para outra. Coisas que deram certo no passado ou em outro mercado, podem não dar certo agora, para sua empresa. Ou seja, a execução é algo que também depende de sorte e de alguma experimentação. Claro que existem coisas que são atemporais e independente de mercados ou indústrias – gestão de pessoas, finanças, estoque, algumas automações etc. Uma empresa depende de tantos processos e de tanta gente para funcionar que uma parte dela, com certeza, será particular ou diferente do restante.

Não sei se consegui me fazer entender, e por isso aqui vai o resumo:

• Duas das maiores e mais afinadas mentes científicas de nosso tempo argumentam que o sucesso de uma empresa depende de sua estratégia e da execução dessa;
• Adotar uma estratégia é igual a descartar TODAS as outras estratégias possíveis;
• Não é possível saber de antemão qual estratégia vai dar certo, e qual vai dar errado;
• Implantar (executar) essa estratégia é algo que depende de conhecimento, experimentação e sorte.

Melhorou? Leiam o livro do Rosenzweig para uma iluminação maior, mas se você acha que entendeu a lista acima, beleza, consegui o que eu queria. Próxima pergunta:

Como Escolher uma Estratégia?

O Rosenzweig discute isso brevemente. Resumindo, não dá para competir com todo mundo, em todos os mercados, oferecendo todos os produtos para todos os clientes. É preciso fazer escolhas, é preciso tomar decisões, como por exemplo:

1. Em que mercado vamos atuar?
2. Que produto vamos oferecer?
3. Contra quem vamos concorrer?
4. Vamos vender por menos que a concorrência, ou cobrar um prêmio por mais qualidade/conteúdo/rendimento/etc?
5. Quanto os clientes estão dispostos a pagar?

Como Executar a Estratégia?

Larry Bossid disse que “Nenhuma estratégia entrega resultados a menos que convertida em ações específicas.” Uma vez que a estratégia foi escolhida, a execução precisa ser suficiente e isso implica em fazer mais escolhas. É irreal pretender executar 100% das atividades possíveis e ter 100% de qualidade em 100% das vezes. É preciso escolher no que investir tempo e recursos, e decidir que atividades serão deixadas de lado ou terão menos atenção.

A diferença entre a execução e a estratégia é que a estratégia depende muito do que está fora da empresa, e a execução depende quase que totalmente do que está dentro da empresa.

Ou seja, se a sua empresa ainda não existe, se ela é só um Plano de Negócios, você precisa de dados gerados por outrem. Você não tem nada, e precisa pesquisar tudo. Você ainda não sabe nada sobre seu (futuro) negócio, tudo são estimativas, chutes e palpites.

Você faz o melhor que pode para tirar a empresa do papel, e durante um tempo voa por instrumentos, meio às cegas, contando com a melhor informação que você conseguiu acumular e seu taco para o negócio.

Uma vez que sua empresa passou a existir, dados começaram a ser gerados – pedidos, itens produzidos, serviços prestados, clientes adquiridos e perdidos, lucratividade, competição, market share etc. etc. etc. A partir daí você pode avaliar se está indo bem ou não. Você consegue dizer se está executando bem, ou não, se sua estratégia está dando certo, ou não.

Inteligência de Negócios, Estragégia & Execução

Rosenzweig conclui, no capítulo nove do Halo Effect, que executar brilhantemente uma estratégia de sucesso pode levar uma empresa à falência. Se o mercado mudar, se a tecnologia mudar, se a concorrência mudar – se alguma coisa mudar o mundo no qual sua empresa existe –  sua empresa vai ficar vulnerável, e a única forma de lidar com isso é estar sempre atento e, eventualmente, decidir mudar de estratégia, antes que seja tarde demais. No final deste capítulo, Rosenzweig cita Tom Peter de novo:

Para ser excelente, você precisa ser consistente. Quando você é consistente, você é vulnerável a ataques. Sim, é um paradoxo. Vire-se com isso.

E como você decide que é hora de mudar de estratégia? Como você descobre se o problema não é estratégia, mas sim execução? Ou o inverso?

Uma empresa é uma coisa viva, que existe em um mundo em constante mutação. Organizações podem ser entendidas em si, e em seu meio-ambiente, por um único indivíduo até certo tamanho: uma padaria, uma farmácia, uma escola – um supermercado, talvez. Acima de um certo tamanho, as interações dentro da empresa, e da empresa com o meio externo são tão numerosas e complexas que uma só pessoa não consegue abarcar em sua mente toda aquela informação e tirar sentido dela. A partir de um certo tamanho, repensar a estratégia e avaliar a execução passa a ser uma tarefa sobre-humana.

E é nesse ponto que se encontra o valor da Inteligência de Negócios. A captura e análise sistemática de todos os dados que sua empresa gera, e se possível, dados do mercado e dos clientes, só pode ser feita com ferramentas específicas. Essas ferramentas se separam em duas categorias: acúmulo de dados e análise de dados. Armazéns de Dados (Data Warehouses) cuidam do acúmulo. Ferramentas como OLAP e Data Mining cuidam da segunda. Recursos de apresentação, como painéis e relatórios, comunicam os resultados para a empresa, e servem como guias para avaliar o risco da estratégia atual, para avaliar a qualidade da execução em curso.

Inteligência de Negócios é a disciplina que habilita uma empresa a buscar alto rendimento.

Juntando à conclusão do post anterior:

Inteligência de Negócios é a disciplina que habilita uma empresa a buscar alto rendimento através da compreensão de seu negócios mediante a aplicação do Método Científico.

Fechou, é isso. Até a próxima.

Lavando Louça (ou Paz, Afinal III)

Todo mundo que lava louça em casa sabe que essa é uma atividade mecânica, meio que automática depois de um tempo, e também sabe que nesta situação a mente fica ociosa e acabamos pensando em qualquer coisa.

Bom, então, eu estava lavando louça esses dias e me lembrei de uma conversa que eu tive no LinkedIn, e só então me dei conta da importância do que foi discutido. O restante da discussão não vem ao caso, mas eu posso contar o santo: o autor, Diego Elias, propunha uma contextualização de BigData em BI. No meio da conversa eu soltei:

No meio da bagunça (entendeu o lance das faixas pretas?) eu soltei essa.

Try to See the Truth:

There Is No Spoon.

Eu simplesmente não aguento mais fazer posts sobre definições de coisas fundamentais, e o mundo está até as tampas de literatura especializada, feita por gente muito melhor do que eu, de modo que tudo que eu possa falar é completamente redundante. Mesmo assim…

Mesmo assim, nas minhas turmas de BI eu sempre faço questão de insistir em um ponto:

Try to see the truth: There is no BI.

Neste slide eu sempre mango do Matrix: tente ver a verdade, não existe BI. O slide diz tudo, mas não custa reforçar: BI é uma disciplina, da qual software-houses e fabricantes de hardware se apoderaram, ao ponto de existir uma carreira de Administração de Empresas, mas não uma de Inteligência de Negócios! BI está virando uma piada, como aquela sobre hardware e software(*1), “BI é quem toma a decisão errada, Administração é quem enfia o pé na jaca”.

E, se eu não me engano, até comentei essa idéia com um grande amigo da USP, durante o Pentaho Day de 2014.

Simplesmente

Taylor, em seu seminal livro, preconiza que a gestão empresarial deveria ser uma ciência, com movimentos friamente calculados e ponderados de antemão. É uma idéia tão forte e com tanto apelo que ninguém conseguiu, até hoje, deslocá-la. Todos reconhecem que Administração não uma ciência “no duro”, principalmente porque não é possível criar empresas em placas de Petri, mas mesmo assim tentamos nos cercar de fatos testados para conduzir uma empresa. Por isso fazemos pesquisas de opinião no mercado, por isso entrevistamos e testamos nossos candidatos antes de contratá-los, por isso medimos e tentamos controlar a qualidade dos produtos e processos.

Porque simplesmente faz sentido.

Simplesmente faz sentido relacionar causa (ferramentas sujas, falta de habilidade, material de baixa qualidade) com o efeito (produtos feios, mal-feitos, ordinários.)

Simplesmente faz sentido examinar os números da empresa para descobrir que história eles contam.

Paz, Afinal III: O que é Inteligência de Negócios

Simplesmente:

Inteligência de Negócios é a disciplina de busca da compreensão dos negócios de uma organização mediante a aplicação do Método Científico.

Eu entrei no SAS em abril de 2000. Fiz essa pergunta a um sem-número de pessoas, começando pela Country Manager do SAS em 2000 (é tomar decisões com ferramentas – grosso modo, já não me lembro bem o que ela falou), passando por todos os meus colegas de SAS, depois por um VP de vendas do SAS, daí para pessoas em indústrias, bancos, varejo, o pessoal da MicroStrategy, várias pessoas no meu emprego, fóruns etc. Sem contar os livros que eu li (li tanto que um dia botei tudo para fora e escrevi meu próprio) e mesmo assim eu não tinha nenhuma resposta. Nenhuma boa o bastante, simples o bastante, nenhuma que eu pudesse ler quando não soubesse o que fazer, que caminho seguir. Eu costumava usar a do livro do Swain Scheps, BI for Dummies, e ela fazia isso por mim.

Eu procuro essa definição há quase 15 anos. Obviamente eu não perguntei à pessoa certa, e deixei de ler exatamente o livro que tinha essa definição. Infelizmente eu continuo não sabendo qual é – quem sabe um dia eu encontro um dos dois. ;-)

Até a próxima.

---

 

(*1) Odeio notas-de-rodapé, mas não queria quebrar o raciocínio lá em cima: perguntado sobre a diferença entre hardware e software, o cara responde que “hardware é o que você chuta, software é o que você xinga”. :-) É engraçado porque é verdade…

Como um Data Vault Evolui

Ontem eu estava mexendo no meu projeto de DV de estimação (um aconselhamento que presto a um amigo) e descobri uma coisa: o satélite dos dados dos empregados tinha centenas de registros por empregado. Eu fui olhar de perto e descobri que não eram centenas, mas sim um por dia desde o início da captura dos dados. Para um DV, isso significa que a cada refresh (que é diário neste caso) o ETL está versionando o satélite de empregados. Como isso só aconteceria se todo dia houvesse alguma diferença para a última versão, eu decidi analisar os registros, comparando as versões de satélites para um empregado qualquer.

Eu vou mostrar algumas imagens para ilustrar o que eu fiz, mas saibam que todos os nomes foram mudados para coisas mais óbvias, e campos particulares (que possuíam detalhes da arquitetura do sistema) foram removidos. São ilustrações, não são o caso real, ok? Exceto por esse detalhe, todo o restante é a narração fiel do que eu fiz.

O satélite Empregado, mostrado na figura abaixo junto ao hub Empregado, tem cerca de 13 campos do sistema de origem, mais 4 de controle do DV.

Satélite empregado original, com todos os campos em uma única tabela.

Todos esses campos estão em uma única tabela no sistema de origem, de modo que a carga desse pedaço do modelo é feito por duas transformações: uma de hub e uma de satélite.

Eu descobri, depois de analisar o conteúdo do satélite, que três campos eram atualizados sempre que o empregado chegava para trabalhar e depois ia embora:

• emp_ultimo_acesso
• emp_ultimo_ip
• emp_ultima_sessao

Na verdade, sempre que o empregado fazia login (e depois logoff) em qualquer computador na empresa, esses detalhes são atualizados. Resultado: todo dia eles estavam diferentes do dia anterior, a menos que o empregado tivesse faltado, ou o dia anterior fosse um feriado/fim-de-semana. Portanto, todo dia um novo satélite era carregado, e isso estava correto. O ETL estava fazendo o que havia sido programado para fazer.

Satélites Separados

Temos aqui uma situação clássica para Data Vault: o sistema de origem tem taxas de atualização diferente entre os atributos. Alguns são atualizados uma vez na vida e outra na morte, e outros são alterados todos os dias, quando não várias vezes por dia. Se capturarmos todos os registros na mesma tabela estaremos desperdiçando tempo e espaço em disco, tratando e gravando coisas duplicadas, desnecessariamente.

Neste caso optamos por quebrar um satélite em dois ou mais, em função de sua taxa de atualização: um satélite conterá apenas os três campos que mudam todos os dias, e o outro satélite ficará com os campos mais estáveis. Cada um terá sua própria transformação para carga. No final, nosso DV vai ficar assim:

Satélite Empregado, agora quebrado em duas tabelas em função da taxa de atualização.

Aplicando a Mudança

Antes havia um satélite (=uma tabela), com todos os campos, carregada por uma transformação. Depois teremos duas tabelas, cada qual com seu conjunto de campos, e cada qual carregada por sua transformação. Eis o passo-a-passo que eu passei para meu amigo aplicar em produção:

1. Renomear o satélite original para s_empregado_antigo;
2. Criar as duas novas tabelas, s_empregado e s_empregado_1;
3. Popular cada uma com o histórico atual;
4. Apagar o satélite original;
5. Subir as duas novas transformações.

As novas tabelas foram criadas e populadas de uma só vez com um SELECT INTO (o DV está em Postgres, o que facilita tudo.) As transformações foram criadas semi-automaticamente (basta entrar os nomes das tabelas, campos e da transformação e um script parametrizado gera tudo sozinho.)

Pronto! Quinze minutos depois de diagnosticar o problema eu tinha desenhado a solução. Meu amigo avisou que aplicou e deu tudo certo e agora vai propagar a solução para outros satélites (ele tem vários desses com status instantâneo.)

(Bom, vá lá, eu demorei um pouco mais que quinze minutos porque deu um trabalhinho até eu acertar o SELECT – ele precisava manter o histórico, o que significa dois SELECT DISTINCTs, com ORDER BY etc. Mas agora eu já sei o macete, e da próxima vez vai ser só 15min mesmo!)

Outras Quebras

Outras opções de quebras para satélites são por sistema de origem, que dá a vantagem de integrar os dados já no DV, e por particionamento. Neste último podemos deslocar satélites estáveis para outras mídias (outros tablespaces), e continuar a carregar os novos em uma tabela menor.

O Que Kimball Faria?

Meu grande amigo Gurgel que me perdoe, mas eu não vou nem considerar essa situação na 3NF. Agora, como ficaria essa situação em um Modelo Dimensional?

Na verdade, ficaria muito bem, obrigado! Veja, Modelagem Dimensional é uma técnica resiliente e robusta, com muita flexibilidade. Teríamos praticamente a mesma abordagem: quebrar uma tabela (de dimensão) em duas, criar dois novos processos de cargas (duas novas transformações), e recriar a fato, agora com duas chaves no lugar de uma só.

Factível, viável e simples, sim. Interessante? Não tenho certeza: hoje esses dados não possuem nenhum interesse para o negócio do meu amigo. São dados que ele descartaria sem pensar duas vezes – e foi essa a primeira sugestão dele. Saber qual é a hora do último logoff de cada empregado não tem o menor impacto no rendimento da empresa, nem a menor relação com a produtividade desse empregado. É um dado pura e simplesmente inútil, e só entrou no satélite porque simplificamos o levantamento de requisitos ao mínimo essencial – o também clássico carrega tudo!.

O Que Linstedt Faria?

Tá bom, saber quando o empregado fez o último logoff do dia é inútil. Mas e saber o histórico completo de todos os logins e logoffs, interessa?

Veja, estamos falando de capturar todas as mudanças, até mesmo em tempo real se for necessário. Para conseguir isso, sem gastar muito, basta rodar apenas a transformação que carrega esse satélite (com um ajuste para a variável de tempo – detalhes que não vêm ao caso agora…) a cada hora ou minuto. Com algumas centenas de empregados esse processo seria muito leve.

No caso mais extremo, dá para agendar uma PROC no banco que faça isso, e descartar o PDI completamente, reduzindo ainda mais o impacto da captura de histórico.

Com esses dados, novas perguntas são possíveis:

• Será que um empregado que entra e sai do sistema várias vezes produz menos?
• Preciso me preocupar com isso?

Um modelo dimensional permite capturar isso se você quiser. Basta montar uma estrela só para isso, já que esse vai ser o processo de negócio em análise.

Agora, e aqui vem uma das coisas legais do DV, um Data Vault te permite capturar isso já integrado com os outros satélites, o hub e tudo o mais. Um bom desenhista dimensional sabe que a técnica do Kimball também te dá essa possibilidade. Mas quanto mais você extende seu DW Dimensional com esse tipo de recurso, mais chega perto de um modelo Data Vault! A quantidade de dimensões e inter-relações (o Bus Matriz) começa a crescer, e a gestão vai ficando cada vez mais difícil. Apesar de flexível, a Modelagem Dimensional não é pensada para acumular dados, mas para análisá-los e por isso, cedo ou tarde, se seu DW muda com frequẽncia, um DV vai se tornar uma alternativa interessante.

E então você vai testar, só para ver como seria. E, então, já será tarde demais. Você será fisgado, como eu fui.

Até a próxima! Fui! :-)

Packt Video Review – Building a DM with PDI

This video, Building a Data Mart with Pentaho Data Integration, teaches how to apply the Kimball Dimensional Modeling technique with Pentaho Data Integration tool. At the beggining it disclaim it will not teach Dimensional Modeling or how to use PDI. Considering how sophisticated Kimball’s technique is, the content is very usefull for anybody how has to assembly such Dimenional Data Marts.

I liked it very much:

• The video has very high quality: 1920×1080 @ 25 fps and 44KHz audio stream.
• The video capture is very fluid, very stable, no skipping. The machine on which it was recorded is blazing fast, and paired along Ubuntu it just screams – no loading times, no lags, only smooth movements. You can see it is not an edited video because most of the time the mouse cursor does not do leap around the screen;
• The product is not only a video feed, it has a whole site with the video splitted in sections, make it easy and an ease to navigate, to play, stop and resume;
• The narration is very concise and sparingly (no hums and ehhs or silences.) You can see it has been edited to reach this quality;
• The product is very complete, with downloadable material;
• It is totally based on FOSS community editions softwares, so no extra cost at all to follow it (although it does use Pentaho Analyzer, but a free limited feature license one – very high added value because this is a very usefull tool;)
• It shows en passant how to use the EObjects Data Cleaner to achieve better data quality, which is a huge plus just by mere mentioning it;
• It is a very good course because it address not only the promised subject with detail, but it also teaches a lot on important aspects of data warehousing, like using columnar databases, caring about data quality, file and database versioning etc.;
• Most of the technical decisions are justified, which means you bask on the author experience.

I didn’t like it:

• The narrator has an accent with gets in the middle sometimes (I could never fully understand the second part titles), but you get accostumed to it. Also, I believe they’ve changed narrators a couple of times or maybe changed the pitch – the guy sounds a bit different at some chapters. No big deal;
• The sound has some volume and pitch wobling: sometimes (and quite frequently) it sounds like having skipped a frame or two and the voice goes into a higher pitch while decreasing the volume a bit. However, other than a little irritanting, it does not impair the hearing and you eventually also get accostumated to it;
• The use of JNDI connections: PDI has variables which are better fit to make connections portable than JNDI. However, it is a technical option you don’t need to follow and it does not negativelly affect the video or the content and its usability;
• On the Packt off-line video interface I missed very much some buttons to replay the video or go back a little, pause it and so on. When you download and play with your favorite media player everything is ok, tough.

Conclusion

I could go on and on listing things I liked about this video, but I’d became repetitive. On the other hand, the bad things are not really important. Besides the listed above, I could hardly find anything else.

Packt’s video has very high quality.

The content is rich, detailed, carefully organized and laid out, very usefull and very practical. The video itself is very good, worth an in person course, technically very well done, and with a nice off-line interface. The negative points amounts to some quirks of the audio and the offline interface navigation buttons that I miss, but none of them are really important and do not stand in the way for an enjoyable experience.

All in all, Building a Data Mart with Pentaho Data Integration is a buy if you need to learn how to use PDI to design an ETL process for loading a Dimensional Model.

Relação sem Causa (ou Paz, Afinal II)

Recentemente me foi recomendado ler The Halo Effect, que saiu no Brasil com o nome de Derrubando Mitos, de Phil Rosenzweig. Bom, o Efeito Halo é um viés cognitivo no qual a impressão geral de o observador sobre uma pessoa influencia os pensamentos e emoções do observador sobre aquela pessoa. Em miúdos, se você acha uma pessoa boa, vai ter dificuldades em crer que ela possa fazer maldades, e vice-versa.

O livro é interessante em si, e vale a pena lê-lo, mas além da questão do halo ele ainda investiga várias outras ilusões da administração moderna. Uma delas é A Ilusão da Correlação e Causa (página 72/locação 1318.) Ele explica que achar uma correlação entre duas ou mais variáveis é só metade da história. A outra metade é saber que variável(is) afeta(m) que outra(s) variável(is). Assim, argumenta ele, se você quer entender a relação entre a causa e o efeito de um problema, você precisa capturar os dados ao longo do tempo. Examinando dados atemporaisde um evento podemos até descobrir que duas variáveis estão correlacionadas – que a variação de uma está atrelada à variação de outra. Mas sem investigar essa relação ao longo do tempo não conseguimos saber qual variável causa variação e qual sofre a variação. (O slogan da Tostines me vêm à cabeça, mas acho que não tem nada a ver…)

E este é o ponto no qual eu queria chegar: você quer usar os dados da sua empresa para melhorar seus resultados? Jóia, é isso que chamam de “fazer BI”, e para isso você precisa de ferramentas de BI. Mas, acima de tudo, a coisa mais importante para você chegar a conclusões de qualidade é dispor de histórico desses dados.

Em outras palavras, analisar os dados instantaneos, simplesmente copiando os dados do seu transacional e metendo uma ferramenta em cima, não vai te ajudar muito. Na verdade, pode até ser perigoso.

DW Para Que Te Quero!

O título alternativo deste post é Paz, Afinal II. No primeiro post Paz Afinal, eu explicava que finalmente tinha chegado a uma conclusão sobre a utilidade de um DV.

Depois de ler esse trecho do The Halo Effect, eu finalmente resolvi uma questão ainda mais importante (para mim) e para a qual eu não conseguia ver nenhuma resposta: para quê, afinal, eu preciso de um DW?

A resposta clássica era “para ter histórico”. Mas isso é o “porque Deus quis” do BI! Não é uma resposta! Pode ser uma justificativa – eu construo um DW para guardar histórico – mas não diz porque, raios, alguém precisa de histórico.

É fácil responder “porque precisamos de histórico?” dizendo “para analisar sazonalidade”, mas isso também não é resposta. A sazonalidade é uma dependência temporal de uma variável e por isso eu preciso da data de cada observação para analisar essa relação. Mas isso não justifica a necessidade do histórico porque é o mesmo que dizer que a quantidade de vendas depende do preço do produto – eu preciso coletar o preço e as quantidade vendidas. Eu preciso coleta tempo e métricas para analisar sazonalidade.

Não, não é tão simples. E mesmo assim, um DW se justificaria em apenas um caso – da sazonalidade. É muito pouco.

O Sr. Rosenzweig me ofereceu a resposta óbvia, genial em sua simplicidade:

Soluções de Inteligência de Negócios precisam de Armazéns de Dados (que guardam histórico) porque precisamos analisar a relação de causa e efeito entre as variáveis.

É isso. Até a próxima! ;-)