Procure-to-Pay: Roadmap de transformação

Transformar operações da área de Finanças e Contabilidade passa pela adoção de ferramentas digitais e pela utilização de dados para melhorar não apenas a operação, mas principalmente os resultados financeiros da companhia.

Entre os fluxos de trabalho desse domínio financeiro e contábil, o Procure-to-Pay, ou apenas P2P, é um dos que tem se beneficiado muito pela aplicação inteligente de ferramentas.

Mas o que é o P2P afinal? Procure-to-Pay (Comprar-até-Pagar, em tradução livre) é o termo designado para o ciclo de transações que vão desde a aquisição de um produto ou serviço até o pagamento ao fornecedor. Na maior parte das organizações é onde a maior fatia de dinheiro está sendo gasta, e portanto é uma atividade chave.

Desafios atuais dessa área são muitos, mas contribuir para o correto planejamento de fluxo de caixa, evitar perdas e assegurar compliance com normas internas e legais são os mais comuns.

Melhorar ou transformar esses processos significa simplificá-los, reduzir tempos de ciclo das transações, aumentar produtividade, reduzir erros e dar maior visibilidade e previsibilidade financeira. Tudo que um CFO sonha durante a noite.

Ao reduzir o tempo de ciclo do processo as compras urgentes – que normalmente custam mais caro – diminuem, e os usuários também ficam mais satisfeitos com recebimentos rápidos. Redução de erros evita retrabalhos, reconciliações e perdas financeiras.

Também fornecedores de produtos e serviços se beneficiam por pagamentos no prazo e o relacionamento melhora para ambos os lados.

Pilares da transformação do P2P

RPA (Robotic Process Automation) é hoje uma das ferramentas chave para reduzir atividades manuais e repetitivas. Transferir informação de um e-mail para um ERP, por exemplo, pode ser feita automaticamente. A ferramenta também pode transferir dados de uma tela para outra – quando sistemas não conversam, fazer uma transação em um website, enviar e-mails automaticamente, e assim por diante.

Alie-se a isso soluções de OCR (Optical Character Recognition – Reconhecimento de Caracteres) ou ICR (Intelligent Character Recognition – Reconhecimento Inteligente de Caracteres) que podem ler informações de formulários, imagens, documentos digitalizados, inclusive escritos manualmente.

Soluções de Workflow automatizadas também ajudam a retirar o trabalho transacional do modo manual e não padronizado. Tarefas e informações são direcionadas para as pessoas corretas, evitando erros e perda de informação, não-cumprimento de prazos e desvios de procedimento.

Em cima disso há a utilização de dados para melhorar a tomada de decisão, reportar corretamente as informações financeiras e também beneficiar o dia-a-dia operacional.

Ferramentas de Analytics exploram os dados das transações em diversas etapas e podem dar mais luz ao que está acontecendo na empresa. Ao examinar histórico de preços de um produto, por exemplo, pode-se prever qual o valor que será praticado pelo fornecedor no próximo ciclo de compras e dar mais argumentos ao time de Compras para negociação.

Também pode-se dar mais visibilidade e previsão a indicadores como valor médio de PO (Ordem de Compra), Variação de Preços X Indicadores Econômicos, Fluxo de pagamentos, entre outros.

Algoritmos de Machine Learning, desenvolvidos com base em dados históricos e integrados nas aplicações da empresa podem ser úteis para auxiliar na tomada de decisão ou mesmo na tomada de ações automaticamente.

Uma aplicação utilizada é o 3-way-match, nome chamado ao cruzamento de informações entre o pedido de compra, dados do que foi recebido efetivamente (conhecimento de transporte, por exemplo) e a nota fiscal enviada pelo fornecedor. Variações significativas entre os documentos significam erro e o pagamento pode ser interrompido.

Outra aplicação de Machine Learning também é detecção de fraudes. Ao avaliar compras suspeitas o sistema pode emitir alerta ou mesmo interromper a transação.

Todas essas ferramentas beneficiam o processo, permitindo gastos precisos e planejamentos confiáveis. E ao menos ao que concerne ao P2P, a empresa poderá se vangloriar de ter um fluxo de caixa saudável.

Comece o projeto pelo fim

Muitos já leram – ou ouviram falar – dos famosos 7 Hábitos de Pessoas Altamente Eficazes, de Franklin Covey. Não é um bestseller por acaso, e apesar de não ser adepto à literatura de auto-ajuda, creio que há um ponto aqui em que ela encontra o mundo real.

O segundo hábito descrito por Covey – atenção para spoiler – é “Comece com o Fim em Mente”. No livro o autor pede que o leitor imagine/visualize seus objetivos sendo realizados, pois com essa visualização será capaz de encontrar melhor os caminhos e motivar-se para o atingimento dos objetivos.

E como isso me ajuda na prática?

Ter o Fim em mente é muito útil durante a concepção de um projeto ou mesmo na elaboração de uma apresentação. Ao saber qual o resultado que você quer ter, fica mais fácil elaborar o caminho até ele, ou ao menos saber que perguntas fazer.

Podemos considerar também o Fim como o início de um processo iterativo, pois ao longo do tempo será amadurecido até chegar em uma ideia definitiva. Você imagina os clientes com um novo telefone na mão, mas no dia seguinte o que você tem é um protótipo em play-doh. E, acredite, isso é um belo começo!

No caso de projetar um novo produto ou processo pode-se imaginar o Fim como o processo definitivo: visualizando usuários operando um novo sistema, uma transação mais simplificada, um produto seguindo por uma logística diferente, pessoas utilizando o seu produto, e assim por diante.

Ao fazer esse exercício você gerará muitas perguntas. Como farei isso? Quanto vai custar? Quem poderá produzir minha matéria prima? Quanto tempo vai levar? E por aí vai… Perguntas extremamente relevantes e que devem ser respondidas, e uma vez respondidas você terá mais clareza do Como Fazer.

Uma pergunta importante nessa fase: posso fazer um protótipo/piloto? Com a visão do Fim é mais fácil pensar como seria um piloto ou MVP (Produto Mínimo Viável).

O mesmo processo mental se aplica para uma apresentação. Ao ter em mente o resultado final (pode ser um Sim para um projeto, um aperto de mão fechando um negócio, ou um elogio por um bom trabalho), pode-se trabalhar no conteúdo para que aquele resultado seja obtido.

Para aprovar um orçamento você imagina as perguntas que podem ser feitas, o material que você apresentará, como apresentará, quem estará presente, que argumentos e contra-argumentos serão apresentados, e assim por diante. É útil também pensar no Fim como um resultado negativo. Neste caso, o que você fará para reverte o resultado?

E voltando ao lado mais conceitual, ter o Fim Em Mente significa que você sabe aonde exatamente você quer chegar. Ter uma equipe ou projeto que não tem um direcionamento objetivo e um foco claro é uma receita para fracasso e que auto-ajuda não poderá resolver.

Tutorial R: Usando as tabelas do SQLite

SQLite é um banco de dados SQL gratuito para utilização local (desktop). Como o próprio nome (lite) diz, ele é muito leve e fácil de usar, seja diretamente na linha de comando ou usando uma GUI como a SQLite Studio.

Neste post mostro como conectar uma base de dados do SQLite usando os pacotes DBI e RSQLite.

# Primeiramente instale os pacotes (caso você ainda não os tenha) com o comando install.packages:

# install.packages('DBI')
# install.packages('RSQLite')

# Depois é só carregá-los:

library(DBI)
library(RSQLite)

O pacote DBI funciona para conexões com vários banco de dados (MySQL, PostgreSQL e outros), porém ele necessita do drive específico para o banco de dados que você está utilizando, o que é fornecido pelo RQSLite.

Como a conexão do banco de dados SQLite é local, é necessário especificar o local do banco de dados.

caminho <- 'C:/Users/eron0/db/homedb.db'

Então é criado uma conexão que usará o RSQLite como driver, usando o commando dbConnect()

con <- dbConnect(SQLite(), 
                 dbname = caminho )

Pronto! O banco de dados está conectado. Há várias funções que podem ser utilizadas tanto para leitura quando para gravação no banco.

Para uma leitura de dados que serão utilizados para análise, pode-se utilizar o dbReadTable() para ler uma tabela chamada data_table, e em seguida vemos as primeiras linhas.

x <- dbReadTable(con, name = 'data_table')

head(x[,1:5])

##   user_id     full_name process_name process_id leader_id
## 1       1 Zina Reinhold     COBRANÇA         11       268
## 2       1 Zina Reinhold     COBRANÇA         11       268
## 3       1 Zina Reinhold     COBRANÇA         11       268
## 4       1 Zina Reinhold     COBRANÇA         11       268
## 5       1 Zina Reinhold     COBRANÇA         11       268
## 6       1 Zina Reinhold     COBRANÇA         11       268

O pacote DBI também admite uso dos comandos SQL para fazer as queries com a função dbSendQuery().

y <- dbSendQuery(con, "SELECT * FROM data_table WHERE user_id = 10")
dbFetch(y, 5)

##   user_id      full_name process_name process_id leader_id     leader_name
## 1      10 Alanzo Fernand     COBRANÇA         11       268 Braylen Juliann
## 2      10 Alanzo Fernand     COBRANÇA         11       268 Braylen Juliann
## 3      10 Alanzo Fernand     COBRANÇA         11       268 Braylen Juliann
## 4      10 Alanzo Fernand     COBRANÇA         11       268 Braylen Juliann
## 5      10 Alanzo Fernand     COBRANÇA         11       268 Braylen Juliann
##            time_stamp     kpi_name        kpi_result kpi_id kpi_type year_ref month_ref
## 1 2018-07-14 09:46:40 % Recuperado 0.533288564124015      1 Numérico     2018         7
## 2 2018-07-25 10:13:20 % Recuperado 0.992289546805205      1 Numérico     2018         7
## 3 2018-07-28 06:13:20 % Recuperado                 1      1 Numérico     2018         7
## 4 2018-08-07 23:06:40 % Recuperado 0.470217440579712      1 Numérico     2018         8
## 5 2018-08-15 04:53:20 % Recuperado 0.289438049463574      1 Numérico     2018         8
##   data_id
## 1    1367
## 2    1368
## 3    1369
## 4    1370
## 5    1371

E para finalizar é sempre necessário desconectar o banco de dados

dbDisconnect(con)

## Warning in connection_release(conn@ptr): There are 1 result in use. The connection will be
## released when they are closed

Todos os comandos e documentação estão disponíveis no site do RStudio.

Robôs Racistas, Desemprego e Minorias: Preocupações éticas da transformação de processos

Quais são as questões éticas comuns enfrentadas em projetos, especialmente aqueles de transformação dos negócios?

Grande parte das organizações atualmente possui Códigos de Ética, formalmente comunicados e  distribuídos a todos os empregados, seja num livreto ou em um treinamento online. Esses documentos costumam cobrir os aspectos básicos de compliance,  conflitos de interesses e ações anti-corrupção principalmente. 

Mas seguir o código de ética da firma não é, necessariamente,  o suficiente para se considerar um profissional ético. E trabalhando com projetos de melhoria de processos  há diversos desafios que não estarão cobertos pelo Código.

Desde Sócrates, 7 séculos A.C., os filósofos discutem a definição de ética e o que isso reflete em nosso comportamento individual e como sociedade.  Eu, particularmente, gosto da definição de Kant:

Age como se a máxima de tua ação devesse ser erigida por tua vontade em lei universal da Natureza.

Imperativo Categórico de Kant

Mas como também quero tornar essas orientações em algo prático, de maneira a ter uma Régua Ética, então simplifico isso como “imaginar se minha ação ou ideia pode ser generalizada para todos”, ou seja: se eu posso fazer, todo mundo pode também,  e isso é bom!

Algumas das preocupações ou dilemas éticos que presenciei durante projetos são óbvias de diferenciar o certo do errado, outras nem tanto, e devem ser colocadas ao lado da Régua ética para avaliação mais criteriosa.

Muitas vezes há intenções ruins numa ação antiética, mas na maioria das vezes acontecem por questões culturais, socioeconômicas ou decisões erradas. Os casos abaixo podem exemplificar alguns dos dilemas éticos e como uma Régua Ética pode ajudar.

1° Caso: O PROJETO VAI TIRAR O EMPREGO DAS PESSOAS

Confrontado com uma questão dessas, o líder responderia a verdade nua e crua e assim lidar com possível evasão de pessoas e falta de apoio na condução do projeto?

Ou seria melhor omitir (mentir) dizendo que não há com o que se preocupar, e que tudo vai dar certo pra todos – quando na verdade não irá?

Minha primeira leitura é que é melhor falar a verdade uma vez, e logo cedo – mesmo que doa – do que desculpar-se pela mentira diversas vezes no futuro, e com isso perder sua credibilidade profissional.

Como gerente de um projeto a obrigação é antecipar-se a esse tipo de questão e alinhar a comunicação previamente com os stakeholders.

Pela Régua Ética, se em todos os projetos nós não deixamos claros qual a intenção e o impacto para as pessoas, isso seria bom ou ruim para o grupo? Creio que a resposta aqui é obvia.

2° Caso: TRATAMENTO DIFERENCIADO DE MINORIAS

É fácil dizer que não há discriminação de raça, cor, orientação sexual e etc., porém aplicar na prática, sabemos, não é simples.

Dentro do contexto de melhoria contínua, especialmente no que tange a performance dos indivíduos, é fácil colocar o interesses econômicos à frente do benefício das pessoas e sociedade.

Um exemplo é descobrir que a produtividade um grupo, digamos, de indivíduos homens jovens e solteiros é melhor que de mulheres casadas com filhos pequenos e com isso criar uma política, mesmo que informal, de preferir um grupo em detrimento de outro.

3° Caso: ROBÔS RACISTAS

Outra preocupação é com automação. Inteligência Artificial e Machine Learning estão cada vez mais tomando as decisões que outrora eram exclusiva de humanos. Estes algoritmos são construídos com base em massas de dados que eventualmente retratam o racismo estrutural da sociedade.

Então, ‘involuntariamente’ cria-se uma automação que discrimina pobres e e os nega empréstimos? Ou quem sabe impede que negros acessem serviços de saúde (Veja esse exemplo)

Conclusão

Líderes e membros de projetos devem estar cientes que transformações envolvem pessoas direta e indiretamente, e o impacto sobre elas deve ser medido também do ponto de vista ético e moral, e não apenas da eficiência e economia.

Alinhe seu projeto com a estratégia da empresa usando OKR

Criado dentro da Intel e popularizado pelo Google, a metodologia de gestão por OKR (Objective Key Results) se destaca pela simplicidade na gestão estratégica e, portanto, uma combinação perfeita com uma gestão ágil de projetos

Um OKR se define por “Eu vou _______ , medido por ______”, sendo a primeira parte a definição do Objetivo e a segunda o resultado, key result. Um OKR de projeto deve estar totalmente alinhado com os OKRs corporativos.

Os OKRs diferem-se dos KPIs tradicionais em sua gestão. Estão intimamente alinhados com a estratégia do negócio e tem um ciclo de conclusão mais curto.

Para um projeto de Melhoria de Negócios, poderíamos colocar alguns exemplos:

“Eu vou melhorar o NPS de clientes, reduzindo o número de reclamações mensais em 20%”.

“Eu vou aumentar a Produtividade, aumentando o número de unidades fabricadas por hora para 150”.

“Eu vou aumentar as vendas, incrementando a visitação no site em 35%”.

OKRs, claro, precisam ter números associados a eles, e um Objetivo pode ter múltiplos – porém nem tantos – KRs. Cerca de 5 KRs para cada objetivo está de bom tamanho.

Outra diferenciação em relação à gestão por Balanced Scorecard (BSC) é que os resultados são muito mais um alinhamento com a estratégia da empresa do que um desdobramento, o que simplifica muito o entendimento por parte de todas as pessoas envolvidas, em todos os níveis hierárquicos.

Voltando ao caso do projeto de Melhoria – seja ele Six Sigma, Lean, Automação, Analytics, Data Science, Implantação de Sistema – o OKR de projeto deve alinhar com o objetivo estratégico da companhia, e também deve ter um ciclo definido para que o objetivo seja reportado e alcançado.

Tipicamente um OKR tem ciclo trimestral, com um acompanhamento mínimo semanal. E como estamos na era dos dados, nada mais justo que um acompanhamento dos OKRs até em tempo real quando possível.

Para exemplificar, temos uma lista de projetos para o mesmo Objetivo estratégico:

ObjetivoKey ResultProjetoCiclo
Aumentar a satisfação dos empregadosRedução de rotatividade mensal em 3%Melhorias de ambiente de trabalho1° Tri
Aumentar a satisfação dos empregadosRedução da rotatividade mensal em 4%Revisão de benefícios2° Tri
Aumentar a satisfação dos empregadosMelhorar resultado da pesquisa de clima em 10%Desenvolvimento de lideranças1° Tri
Aumentar a satisfação dos empregadosReduzir absenteísmo em 8%Projeto Six Sigma3° Tri
Exemplos de alinhamento de OKRs e Projetos

Portanto essa sistemática admite que os objetivos estratégicos permaneçam os mesmos, mas as metas dos projetos (ou dos departamentos) pode ser revisada constantemente, à medida da velocidade de entrega dos KRs.

Há muito mais sobre OKR e sua implementação em toda a organização. Para quem quer se aprofundar em OK, deixo indicado o site do Felipe Castro para um bom começo.

Minhas 3 dicas para uma apresentar dados

Considero a visualização de dados (dataviz) a parte mais divertida de todo o trabalho de análise de dados. Considero que é o momento onde você transforma trabalho bruto em arte visual, que depois será colocado em devida exibição para que o público veja algo mais concreto sobre seu trabalho. Também é o momento da verdade: você pode elaborar algo que dilata a pupila de executivos ou que te deixa em situação constrangedora.

Considero que você já tem um sumário com os dados que quer mostrar, e está pronto para fazer uma apresentação executiva – para seu chefe, chefe-do-chefe, cliente, etc – e precisará colocar em um slide, página web, dashboard, ou algo do tipo.

Então, entre meus erros e acertos, o que aprendi de útil foi o seguinte:

#1 Conheça sua audiência

Não comece o trabalho sem saber para quem você está fazendo, o que essas pessoas querem ver e como vão utilizar o que você mostrar.

Isso vai impactar diretamente no nível de detalhe e o tipo de informação que você irá mostrar.

#2 Não complique

Na construção de informações visuais, menos é mais. Muita informação tira a atenção das pessoas do que realmente importa, e aqui, diga-se, informação de qualquer natureza: cores, linhas, números, texto, imagens, animações. Conforme Edward Tufte, o papa da visualização de dados, você deve passar o máximo de informação, mas com o mínimo de “tinta” possível. O lema KISS (Keep It Simple Stupid) funciona muito bem aqui.

Acredite, uma animação só piora uma informação que já é ruim.

#3 Peça à alguém que revise

Ter alguém que possa criticar construtivamente o seu trabalho não tem preço, pois muitas vezes o que está óbvio para você não está para a audiência. Sem contar aqueles pequenos erros de grafia que deixamos escapar mesmo depois de procurar muito.

Identificando projetos de Analytics

Um Projeto de Analytics é uma iniciativa de melhoria de negócios baseada em uma profunda análise de dados e que entrega um produto final previamente acordado.

Assim como os demais projetos de melhoria e transformação de negócios, essas iniciativas precisam focar na resolução de um problema específico, mesmo que o escopo seja amplo.

O produto ou tipo de projeto de Analytics pode ser dividido nas seguintes categorias:

Análise descritiva

Como o próprio nome diz, nessa análise o objetivo é descrever o que está acontecendo. Dados são analisados dentro de um objetivo de negócio, como mostrar perfil dos clientes que visitam a um site de e-commerce, Análise de vendas por produto e por cliente, Desempenho de linhas de produção, etc.

O produto dessa análise, geralmente um relatório ou dashboards com os dados mais relevantes, dá mais visibilidade do que está acontecendo nos processos estudados.

Análise diagnóstica

É uma análise de dados históricos que é, em fato, uma análise de causa. Ela não só mostra o que está acontecendo mas também diz por quê. Ela pode inclusive responder à perguntas similares a testes de hipótese: Medicamento A é mais eficiente que Medicamento B?, Quem trabalha em home office tem maior produtividade que aqueles que trabalham em escritório?, Qual ação de marketing deu maior impacto nas vendas?

Análise preditiva

Na análise preditiva espera-se prever o futuro (com certa margem de erro, claro). Constrói-se um modelo estatístico utilizando dados históricos e aplica-se este modelo para dados novos/desconhecidos. Modelos aqui podem ser desde simples regressões lineares até redes de Deep Learning, mas que responderão – com certa margem de erro – qual a probabilidade de um cliente fazer uma compra do produto caso ele tenha acessado o site, qual a vida útil de um componente, qual a probabilidade de um político ganhar uma eleição.

Análise prescritiva

Nesta análise você confia ao modelo estatístico a prescrição ou sugestão de uma ação. A decisão em si nem sempre faz parte do pacote, mas os modelos, nesse caso, usarão a opção com maior probabilidade como sugestão de ação.

O exemplo comum é sugestão de produtos baseado em suas visitas ou compras anteriores. O sistema lhe sugere comprar pilhas junto com uma boneca que fala pois diversos clientes fizeram o mesmo no passado.

Também é dessa maneira que um sistema como Uber ou 99 usam para designar um motorista quando você solicita.

A sombra dos processos antigos

Uma questão que sempre assombra os líderes de projetos de melhoria contínua é o fator ‘permanência dos novos processos’. A menos que uma nova ferramenta seja implementada e que o antigo meio de fazer o trabalho seja completamente eliminado, o jeito antigo de trabalhar sempre pode retornar e a melhoria que um dia foi obtida pode ir por água abaixo.

Num processo de gestão de mudanças é sempre crítico avaliar o status quo: há quanto tempo o processo está lá, e há quanto tempo as pessoas estão lá fazendo a mesma atividade? Quanto mais tempo, mais profundas estão as raízes do processo anterior e maior é a chance de que o fantasma do processo anterior retorne.

Também há mudanças que ocorrem à medida que o tempo passa que podem alterar o processo e os respectivos resultados. Novos colaboradores, outra liderança, mudança de produto, novas ferramentas, atualizações de software, e assim por diante.

Uma maneira efetiva de lidar com isso, e uma boa prática para um PMO, é possuir um sistema de auditoria periódico. Revisitar os projetos implementados e garantir que as mudanças implementadas e também os resultados de performance obtidos com os projetos permanecem.

Essa auditoria periódica deve ser mais frequente nos primeiros meses pós-implementação e com menor frequência ao longo do tempo.

E por quanto tempo? Se a organização possui um sistema de qualidade bem maduro, certamente tem um sistema de auditoria de processos que implementará isso de maneira permanente. Caso contrário, até ter certeza de que o processo novo está 100% estabelecido e o fantasma antigo não retornará.

Mapeie os stakeholders e sua influência

Stakeholders são parte essencial, goste-se ou não, de um projeto. E conhecer bem os principais stakeholders do projeto, e não só o patrocinador principal, é essencial para o sucesso, principalmente no que se refere à gestão de riscos.

Se você está conduzindo o projeto com o exclusivo propósito de satisfazer uma única pessoa ou departamento, eu diria que você e seu projeto tem data de validade próxima a expirar.

Nem todos os stakeholders são tratados da mesma maneira, por terem papéis, responsabilidades e poderes diferentes. Isso parece óbvio, mas na prática muitos gerentes de projeto dão pouca diferenciação ao tratamento.

Há diversas ferramentas – e mesmo aplicações, como Smaply e LucidChart – para gestão dos stakeholders, mas que invariavelmente vão mapear:

Poder ou Influência: o quanto a pessoa ou grupo tem a capacidade de influenciam positiva ou negativamente o projeto

Interesse: o quanto a iniciativa do projeto importa para o stakeholder e para seus objetivos. Neste ponto há frequentemente interesses antagônicos, inclusive políticos.

Pessoas com alto poder e alto interesse são a prioridade em termos de satisfação, comunicação e engajamento com o projeto.

Indivíduos com alto poder e baixo interesse devem estar bem informados e devem ser monitorados, de modo a ter certeza de que seu nível de interesse permanece o mesmo

Quem tem baixo poder e muito interesse pode ser muito útil para o projeto, contribuindo com recursos e insights positivos.

Os demais – baixo poder e interesse – são monitorados porém não é necessário investir muitos recursos em comunicação.

Tratar adequadamente cada grupo deve minimizar conflitos entre departamentos, antecipar riscos, garantir recursos e obter maior satisfação com os resultados do projeto.

Tomando decisões baseadas em dados: O ponto de partida

Decisões devem basear-se primeiramente em dados verdadeiros e representativos

Muito se fala em tomar decisões baseando-se em fatos e dados, mas o que acontece na prática é que muitas pessoas ainda tomam decisões com vieses. Dá para gastar um bom tempo lendo Daniel Kahnemann e entendendo dessas “falhas” de julgamento, porém vou me ater à decisão racional sobre dados.

O primeiro passo, creio, é saber se os dados são relevantes, se foram coletados da maneira correta e de uma fonte confiável. Utilizar dados socio-econômicos da cidade de São Paulo para definir políticas para o interior do Tocantins pode ser um exemplo desse tipo de erro, assim como utilizar pesquisas de opinião com o público em geral para um produto que é essencialmente consumido por jovens, como um App de compartilhamento de vídeos.

Os dados também deveriam vir de um sistema (seja ele um dispositivo, um banco de dados ou um formulário de pesquisa) devidamente calibrado, ou seja, que fornece um dado exato (ou com uma margem de erro aceitável) sempre que solicitado – pois ninguém gosta de receber uma resposta diferente para a mesma pergunta!

Há uma bibliografia bem extensa sobre MSA (Measurement System Analysis – Análise de Sistemas de Medição), que é uma forma mais científica de analisar o sistema que está sendo utilizado para medição – neste link tem um livro interessante.