Buone pratiche per l'analisi statistica in un ambiente aziendale

(Anche se mi rendo conto che non si tratta solo di statistiche, si tratta della diffusione di statistiche in un ambiente aziendale, quindi ho ipotizzato che rientri ancora nella gamma di argomenti del CV)

Un po 'di background:

Il nostro ambiente aziendale (e sospetto che altri ambienti) abbiano una funzione di supporto specializzata nell'analisi statistica e nella ricerca. Lavoriamo a stretto contatto con la Business Intelligence e siamo incaricati da altri dipartimenti di produrre pezzi di lavoro. In effetti, i dati, le analisi e le conclusioni non ci appartengono: raccogliamo dati, eseguiamo analisi e traggiamo conclusioni che il commissario può utilizzare nel loro lavoro.

Cosa voglio fare:

Attualmente, adottiamo un approccio al laissez-faire. Un individuo dalla funzione di supporto viene assegnato quando il lavoro viene commissionato, i dati vengono raccolti (o estratti, se esiste, da Business Intelligence), analizzati e il gruppo finale di conclusioni viene inviato al commissario. Ciò è stato vagamente giustificato sulla base del fatto che non è compito del commissario leggere l'analisi; è il nostro ruolo come funzione di supporto per garantire che forniamo la giusta analisi per le domande / gli argomenti che il commissario desidera esplorare.

Voglio invocare un po 'più di struttura sull'approccio da fare

a) la nostra analisi di una qualità superiore;

b) fornire difendibilità quando la nostra analisi può portare a decisioni sbagliate; e fare

c) la nostra analisi più trasparente, quindi non siamo visti come una "scatola nera" che prende i dati e sputa i risultati.

I miei pensieri iniziali sono stati:

1. Produrre un documento tecnico con ogni lavoro che giustifichi l'approccio adottato, le ipotesi formulate, i problemi rilevati, le incertezze esistenti ecc. Sebbene questo non sia necessariamente letto da tutti, dovrebbe essere usato come mezzo per spiegare a al commissario le conseguenze dell'uso delle conclusioni tratte. Ciò trasferisce parte del rischio nel punto in cui sembra che dovrebbe appartenere: al commissario.

2. Limitare tutte le analisi a un pacchetto come Stata, SPSS o R e richiedere che venga prodotto un set completo di codice insieme al documento tecnico. Tutti noi abbiamo l'abitudine di utilizzare Microsoft Excel per alcuni tipi di analisi (cattiva abitudine più di ogni altra cosa). Tuttavia, Excel non promuove la facile riproducibilità dell'analisi. Questo aiuta a difendere la funzione di supporto quando la nostra analisi è messa in discussione, crea trasparenza nel nostro approccio ma rende anche il ruolo di (3) molto più semplice:

3. Assegnare un revisore a ogni opera che deve "controfirmare" l'opera prima che venga inviata al commissario. Controfirmando, distribuisce l'integrità dell'analisi tra 2 persone e le incoraggia a lavorare insieme (2 teste sono meglio di 1). Ciò dovrebbe migliorare la qualità dell'analisi e fornire anche una certa difendibilità.

Ci sono altri aspetti della buona pratica che possono essere applicati in un ambiente aziendale di questo tipo?

Il mio consiglio in due parole ( TL; modalità DR ): ricerca riproducibile .

Per maggiori dettagli - in gran parte per non ripetermi - lasciami fare riferimento alle mie risposte pertinenti altrove su StackExchange. Queste risposte rappresentano i miei pensieri (e alcune esperienze) sugli argomenti:

• pulizia dei dati: /datascience//a/722/2452
• ricerca riproducibile: /datascience//a/759/2452
• report vs. dashboard: /datascience//a/907/2452
• flussi di lavoro di analisi dei dati ed EDA: /datascience//a/1006/2452
• big data e R: /datascience//a/780/2452

Nota finale (scusate, se lo trovate ovvio): indipendentemente dal tipo di ambiente di lavoro (che non è chiaro, tra l'altro), consiglierei di iniziare dal lato degli affari e creare un un'architettura di analisi dei dati , che (come tutto ciò che riguarda l'IT) dovrebbe essere allineato con l'architettura aziendale, compresi i processi aziendali, le unità organizzative, la cultura e le persone. Spero che questo sia di aiuto.

AGGIORNAMENTO: per quanto riguarda la creazione di una nuova o il miglioramento di un'architettura di analisi dei dati esistente (indicata anche come architettura dei dati , nella terminologia dell'architettura aziendale ), ho pensato che anche questi due set di diapositive di presentazione potrebbero essere utili: questo e questo .

Nel settore bancario la modellistica deve essere conforme alle linee guida sulla gestione del rischio modello, come OCC 2011-12 . Penso che sia un documento interessante anche se non sei nel settore bancario.

MathWorks ha questo articolo sugli standard di modellazione.

Poiché la modellazione prevede la scrittura di software in una forma o nell'altra, utilizzo elementi della metodologia di sviluppo del software , in particolare quando si tratta di test e test unitari . Uso anche strumenti di gestione della configurazione del software come SVN. C'è molto che i team di modellazione possono imparare dai programmatori in termini di gestione di progetti software complessi, come sistemi di tracciamento dei problemi e CMS .

Una delle cose più importanti è la metodologia e il processo, il ciclo di vita dello sviluppo del modello. Creare le linee guida su come sviluppare i modelli e testarli, elencare gli strumenti standard e testare ecc. Ad esempio, scegliere uno o due test di bontà di adattamento e utilizzarli ovunque.

Crea modelli di tutto: script di modellazione, white paper, presentazioni ecc. Ad esempio, ho modelli in LaTeX per tutta la documentazione, quindi i nostri white paper sembrano molto simili e tutti sanno dove cercare informazioni. Abbiamo sezioni standard, come statistiche descrittive e colonne standard in esse come kurtosi, prima e ultima data di osservazione ecc.

Prendi il diario di laboratorio. Questa è una cosa che le persone in scienze della scienza dovrebbero aver imparato in dottorato: tenere un diario di tutte le ricerche, idee e soprattutto decisioni. Quando hai deciso di utilizzare ARIMA anziché GARCH, registralo nel diario di laboratorio e descrivi il motivo per cui hai preso la decisione. Lungo la strada le persone tendono a dimenticare la logica alla base delle decisioni, quindi è importante registrarle. Sfortunatamente, le persone che provengono da scienze sociali non hanno l'abitudine di tenere le riviste di laboratorio, è un problema.

Un altro aspetto delle buone pratiche è la disciplina nella fase iniziale della messa in servizio. Ciò potrebbe includere elementi di base come concordare per iscritto ciò che è richiesto dal commissario (per evitare incomprensioni e successive controversie) e chiarire chi nell'azienda ha l'autorità per commissionare il lavoro (un primo passo per garantire che la funzione affronti le esigenze aziendali reali e non indulgere a chiunque abbia una brillante idea).

La disciplina della messa in servizio dovrebbe anche promuovere un dialogo costruttivo prima di concordare i lavori da intraprendere. Quelli che commissionano possono avere una vaga idea di ciò di cui hanno bisogno ma hanno difficoltà a formularlo con precisione, o se offrono una formulazione precisa potrebbe non essere ciò che è più rilevante per le loro esigenze aziendali (ad esempio, potrebbero chiedere un'indagine su le ragioni di un calo delle vendite a breve termine, quando ciò a cui sono veramente interessati sono i fattori a più lungo termine che guidano le vendite). Gli statistici e i ricercatori possono essere bravi a formulare domande o piani di lavoro precisi, ma meno in grado di identificare ciò che sarà utile per l'azienda. Vi suggerisco un parallelo con le buone pratiche nella ricerca accademica che fa una distinzione tra domande di ricercaidentificare argomenti di interesse e ipotesi di ricerca piuttosto ampi all'interno di tali argomenti che siano sufficientemente specifici da condurre a studi di ricerca ben definiti. Pertanto, può essere utile pensare ai commissari come a generare l'equivalente delle domande di ricerca e agli statistici e ai ricercatori come aiutarli a identificare programmi di lavoro più specifici pertinenti a tali domande.

Penso che tu abbia ottenuto parte della tua risposta alla domanda: una "buona struttura" è la chiave.

Sono un ingegnere e ho lavorato in ruoli che enfatizzano un'applicazione simile, in cui ti vengono presentati problemi per fornire assistenza nell'analisi e nel miglioramento dei risultati, ma ricopri un ruolo di consulenza piuttosto che di implementazione.

Gli approcci migliori, che ho visto, sono quelli che non sono troppo prescrittivi o allentati per garantire la giusta quantità di prove che il lavoro è stato svolto con diligenza - che è quello che penso tu stia cercando.

Six Sigma (che è un po 'un termine un po' sporco in alcuni posti in cui ho lavorato) e altre metodologie forniscono un framework per l'approccio, la risoluzione e l'integrazione di una soluzione. Poiché sono basati su un framework, possono essere controllati. La chiave è garantire che tutti siano addestrati nella metodologia E abbiano un buon modello che sia verificabile.

Ad esempio, probabilmente si desidera che le soluzioni siano di uno standard: ciò non è definito dal programma utilizzato, ma piuttosto se è possibile controllare i passaggi dell'analisi utilizzati in un secondo momento e accertarsi che l'attività sia stata completata secondo uno standard. Fornire le pietre miliari - ad esempio i punti di controllo in cui è possibile effettuare l'audit sarà più semplice che provare ad effettuare l'audit alla fine del progetto.

Ritornando a Six Sigma, alcuni approcci potrebbero essere l'audit nella fase Define, dopo Measure and Analyse, e infine alla conclusione (dopo Improve and Control).

Six Sigma non è certamente il migliore in tutte le situazioni, ma posso consigliarlo come potenziale punto di partenza.