Boas práticas para análise estatística em um ambiente de negócios

(Embora eu perceba que isso não é estritamente sobre estatística, trata-se da disseminação de estatísticas em um ambiente de negócios, por isso presumi que ainda esteja dentro do intervalo de tópicos do CV)

Um breve histórico:

Nosso ambiente de negócios (e suspeito que outros ambientes) tem uma função de suporte especializada em análise e pesquisa estatística. Trabalhamos em estreita colaboração com o Business Intelligence e somos contratados por outros departamentos para produzir peças de trabalho. Com efeito, os dados, análises e conclusões não nos pertencem: coletamos dados, realizamos análises e tiramos conclusões para o comissário usar em seu trabalho.

O que eu quero fazer:

Atualmente, adotamos uma abordagem bastante laissez-faire. Um indivíduo da função de suporte é designado quando o trabalho é comissionado, os dados são coletados (ou extraídos, se existir, pelo Business Intelligence), analisados ​​e o conjunto final de conclusões é enviado ao comissário. Isso tem sido justificado com base no fato de que não é papel do comissário ler a análise; é nosso papel como função de suporte garantir que forneçamos a análise correta para as perguntas / tópicos que o comissário deseja explorar.

Eu quero invocar um pouco mais de estrutura na abordagem para fazer

a) nossa análise de uma qualidade superior;

b) fornecer defensibilidade quando nossa análise pode levar a más decisões; e fazer

c) nossa análise é mais transparente, para não sermos vistos como uma 'caixa preta' que coleta dados e divulga resultados.

Meus pensamentos iniciais foram:

1. Produza um documento técnico com todos os trabalhos que justifiquem a abordagem adotada, as suposições feitas, os problemas encontrados, as incertezas que existem etc. Embora isso não seja necessariamente lido por todos, deve ser usado como um meio de explicar: o comissário as consequências de usar as conclusões tiradas. Isso transfere parte do risco para onde parece que deveria pertencer: com o comissário.

2. Restrinja todas as análises a um pacote como Stata, SPSS ou R e exija que um conjunto completo de códigos seja produzido juntamente com o documento técnico. Todos nós temos o hábito de usar o Microsoft Excel para alguns tipos de análise (mau hábito, mais do que tudo). No entanto, o Excel não promove fácil reprodutibilidade da análise. Isso ajuda a defender a função de suporte quando nossa análise é questionada, cria transparência em nossa abordagem, mas também facilita o papel de (3):

3. Designe um revisor para cada trabalho que deve "assinar" o trabalho antes de ser enviado ao comissário. Ao assinar, ele distribui a integridade da análise entre 2 pessoas e as encoraja a trabalhar juntas (2 cabeças são melhores que 1). Isso deve melhorar a qualidade da análise e também fornecer alguma defensibilidade.

Existem outras facetas de boas práticas que podem ser aplicadas em um ambiente de negócios desse tipo?

Meu conselho em duas palavras ( TL; modo DR ): pesquisa reproduzível .

Para obter mais detalhes - em grande parte para não me repetir - deixe-me encaminhá-lo para minhas respostas relevantes em outras partes do StackExchange. Essas respostas representam meus pensamentos (e alguma experiência) sobre os tópicos:

• limpeza de dados: /datascience//a/722/2452
• pesquisa reproduzível: /datascience//a/759/2452
• relatórios x painéis: /datascience//a/907/2452
• fluxos de trabalho de análise de dados e EDA: /datascience//a/1006/2452
• big data e R: /datascience//a/780/2452

Nota final (desculpe, se você acha óbvio): independentemente do tipo de ambiente de negócios (que não é claro, a propósito), eu recomendaria começar do lado comercial e criar uma arquitetura de análise de dados , que (como todos relacionados à TI) devem estar alinhados com a arquitetura de negócios, incluindo processos de negócios, unidades organizacionais, cultura e pessoas. Espero que isso seja útil.

ATUALIZAÇÃO: No que diz respeito à criação de uma nova arquitetura ou à melhoria de uma arquitetura de análise de dados existente (também conhecida como arquitetura de dados , na terminologia da arquitetura corporativa ), pensei que esses dois conjuntos de slides de apresentação poderiam ser úteis: isso e isso .

No setor bancário, a modelagem deve obedecer às diretrizes de gerenciamento de risco do modelo, como o OCC 2011-12 . Eu acho que é um documento interessante, mesmo que você não esteja no banco.

O MathWorks possui este artigo sobre padrões de modelagem.

Como a modelagem envolve escrever software de uma forma ou de outra, eu uso elementos da metodologia de desenvolvimento de software , particularmente quando se trata de testes e testes de unidade . Também emprego ferramentas de gerenciamento de configuração de software , como o SVN. As equipes de modelagem podem aprender muito com os programadores em termos de gerenciamento de projetos de software complexos, como sistemas de rastreamento de problemas e CMS .

Uma das coisas mais importantes é a metodologia e o processo, ciclo de vida de desenvolvimento do modelo. Crie a diretriz de como desenvolver os modelos e testá-los, liste as ferramentas padrão e teste etc. Por exemplo, escolha um ou dois testes de qualidade do ajuste e use-os em qualquer lugar.

Crie modelos de tudo: scripts de modelagem, white papers, apresentações etc. Por exemplo, eu tenho os modelos no LaTeX para toda a documentação, para que nossos white papers pareçam muito semelhantes e todos saibam onde procurar informações. Temos seções padrão, como estatística descritiva e colunas padrão, como curtose, primeira e última data de observação etc.

Tenha o diário do laboratório. Isso é algo que as pessoas de ciências duras deveriam ter aprendido no doutorado: manter um diário de todas as pesquisas, idéias e principalmente decisões. Quando você decidiu usar o ARIMA em vez do GARCH, registre-o no diário do laboratório e descreva por que você tomou a decisão. No caminho, as pessoas tendem a esquecer a lógica por trás das decisões, por isso é importante registrá-las. Infelizmente, pessoas de formação em ciências sociais não têm o hábito de manter os diários de laboratório, é um problema.

Outro aspecto das boas práticas é a disciplina no estágio inicial de comissionamento. Isso pode incluir coisas básicas como concordar por escrito o que é exigido pelo comissário (para evitar mal-entendidos e disputas subsequentes) e esclarecer quem na empresa tem autoridade para comissionar o trabalho (um primeiro passo para garantir que a função atenda às necessidades reais dos negócios e não apenas satisfazendo quem tem uma ideia brilhante).

A disciplina no comissionamento também deve promover um diálogo construtivo antes do acordo sobre o trabalho a ser realizado. Os comissionados podem ter uma vaga idéia do que precisam, mas têm dificuldade em formulá-la com precisão ou, se oferecerem uma formulação precisa, talvez não seja o que é mais relevante para as necessidades de seus negócios (por exemplo, eles podem solicitar uma investigação de as razões para uma queda de curto prazo nas vendas, quando o que realmente interessa são os fatores de longo prazo que impulsionam as vendas). Estatísticos e pesquisadores podem ser bons em formular perguntas ou planos de trabalho precisos, mas menos capazes de identificar o que será útil para os negócios. Sugiro um paralelo com as boas práticas de pesquisa acadêmica, que faz uma distinção entre questões de pesquisaidentificar tópicos bastante amplos de interesse e hipóteses de pesquisa e objetivos dentro desses tópicos, suficientemente específicos para levar a estudos de pesquisa bem definidos. Portanto, pode ser útil pensar nos comissários como geradores do equivalente às perguntas de pesquisa e nos estatísticos e pesquisadores como ajudantes a identificar programas de trabalho mais específicos relevantes para essas perguntas.

Eu acho que você recebeu parte da sua resposta na pergunta - uma "boa estrutura" é fundamental.

Sou engenheiro e tenho trabalhado em funções que enfatizam um aplicativo semelhante - em que você é apresentado a problemas para fornecer assistência na análise e melhoria dos resultados, mas desempenha um papel de consultoria e não de implementador.

As melhores abordagens, que eu já vi, são aquelas que não são muito prescritivas ou frouxas para garantir a quantidade certa de evidências de que o trabalho foi realizado com diligência - que é o que eu acho que você procura.

O Six Sigma (que é um termo meio sujo em alguns lugares em que trabalhei) e outras metodologias fornecem uma estrutura para abordar, resolver e incorporar uma solução. Por serem baseados em uma estrutura, eles podem ser auditados. A chave é garantir que todos sejam treinados na metodologia E tenham um bom modelo que seja auditável.

Por exemplo, você provavelmente deseja que as soluções sejam de um padrão - isso não é definido pelo programa usado, mas sim se você pode auditar as etapas de análise usadas posteriormente e se certificar de que a tarefa foi concluída com um padrão. Fornecer marcos - por exemplo, pontos de verificação nos quais você pode auditar será mais fácil do que tentar auditar no final do projeto.

Voltando ao Six Sigma, algumas abordagens podem ser a auditoria no estágio Definir, após Medir e Analisar e, finalmente, na conclusão (após Melhorar e Controlar).

O Six Sigma certamente não é o melhor em todas as situações, mas posso recomendá-lo como um possível ponto de partida.