Buenas prácticas para el análisis estadístico en un entorno empresarial.

(Si bien me doy cuenta de que esto no se trata estrictamente de estadísticas, se trata de la difusión de estadísticas en un entorno empresarial, por lo que asumí que todavía está dentro del rango de temas de CV)

Un breve resumen de antecedentes:

Nuestro entorno empresarial (y sospecho que otros entornos) tienen una función de soporte especializada en análisis estadísticos e investigación. Trabajamos en estrecha colaboración con Business Intelligence y otros departamentos nos encargan la producción de trabajos. En efecto, los datos, el análisis y las conclusiones no nos pertenecen: recopilamos datos, realizamos análisis y sacamos conclusiones para que el comisionado las use en su trabajo.

Lo que quiero hacer:

Actualmente, aplicamos un enfoque de laissez-faire. Se asigna un individuo de la función de soporte cuando se encarga el trabajo, los datos se recopilan (o se extraen, si existen, por Business Intelligence), se analizan y el conjunto final de conclusiones se envía al comisionado. Esto se ha justificado libremente porque no es el papel del comisionado leer el análisis; Nuestro papel como función de apoyo es garantizar que proporcionemos el análisis correcto para las preguntas / temas que el comisionado desea explorar.

Quiero invocar un poco más de estructura sobre el enfoque para hacer

a) nuestro análisis de mayor calidad;

b) proporcionar defensa cuando nuestro análisis puede conducir a malas decisiones; y hacer

c) nuestro análisis es más transparente para que no se nos vea como una 'caja negra' que toma datos y arroja resultados.

Mis pensamientos iniciales han sido:

1. Produzca un documento técnico con cada trabajo que justifique el enfoque adoptado, las suposiciones hechas, los problemas encontrados, las incertidumbres que existen, etc. Si bien esto no necesariamente será leído por todos, debe usarse como un medio para explicar El comisario las consecuencias de utilizar las conclusiones extraídas. Esto transfiere parte del riesgo a donde parece que debería pertenecer: con el comisionado.

2. Restrinja todos los análisis a un paquete como Stata, SPSS o R y requiera que se produzca un conjunto completo de código junto con el documento técnico. Todos tenemos la costumbre de usar Microsoft Excel para algunos tipos de análisis (mala costumbre más que nada). Sin embargo, Excel no promueve la fácil reproducibilidad del análisis. Esto ayuda a defender la función de soporte cuando se cuestiona nuestro análisis, crea transparencia en nuestro enfoque pero también hace que el papel de (3) sea mucho más fácil:

3. Asigne un revisor a cada pieza de trabajo que debe 'refrendar' el trabajo antes de enviarlo al comisionado. Al contrarrestar, distribuye la integridad del análisis entre 2 personas y los alienta a trabajar juntos (2 cabezas son mejores que 1). Esto debería mejorar la calidad del análisis y también proporcionar cierta capacidad de defensa.

¿Existen otras facetas de buenas prácticas que puedan aplicarse en un entorno empresarial de este tipo?

Mi consejo en dos palabras ( TL; modo DR ): investigación reproducible .

Para obtener más detalles , en gran parte para no repetirme, permítame remitirlo a mis respuestas relevantes en otro lugar de StackExchange. Estas respuestas representan mis pensamientos (y algo de experiencia) sobre los temas:

• limpieza de datos: /datascience//a/722/2452
• investigación reproducible: /datascience//a/759/2452
• informes frente a paneles: /datascience//a/907/2452
• flujos de trabajo de análisis de datos y EDA: /datascience//a/1006/2452
• Big Data y R: /datascience//a/780/2452

Nota final (lo siento, si lo encuentra obvio): independientemente del tipo de entorno de su negocio (que no está claro, por cierto), recomendaría comenzar desde el lado comercial de las cosas y crear una arquitectura de análisis de datos , que (como todo relacionado con TI) debe estar alineado con la arquitectura empresarial, incluidos los procesos empresariales, las unidades organizativas, la cultura y las personas. Espero que esto sea útil.

ACTUALIZACIÓN: En lo que respecta a la creación de una arquitectura de análisis de datos nueva o mejorada (también conocida como arquitectura de datos , en la terminología de arquitectura empresarial ), pensé que estos dos conjuntos de diapositivas de presentación también podrían ser útiles: esto y esto .

En la banca, el modelado debe cumplir con las pautas modelo de gestión de riesgos, como OCC 2011-12 . Creo que es un documento interesante, incluso si no estás en la banca.

MathWorks tiene este artículo sobre estándares de modelado.

Dado que el modelado implica escribir software de una forma u otra, utilizo elementos de la metodología de desarrollo de software , particularmente cuando se trata de pruebas y pruebas unitarias . También utilizo herramientas de gestión de configuración de software como SVN. Los equipos de modelado pueden aprender mucho de los programadores en términos de gestión de proyectos de software complejos, como sistemas de seguimiento de problemas y CMS .

Una de las cosas más importantes es la metodología y el proceso, el ciclo de vida del desarrollo del modelo. Cree la guía sobre cómo desarrollar los modelos y pruébelos, enumere las herramientas estándar y las pruebas, etc. Por ejemplo, elija una o dos pruebas de bondad de ajuste y úselas en todas partes.

Cree plantillas de todo: guiones de modelado, documentos técnicos, presentaciones, etc. Por ejemplo, tengo las plantillas en LaTeX para toda la documentación, por lo que nuestros documentos técnicos se ven muy similares y todos saben dónde buscar información. Tenemos secciones estándar, como estadísticas descriptivas y columnas estándar en ellas, como curtosis, primera y última fecha de observación, etc.

Tener el diario de laboratorio. Esta es una cosa que la gente de ciencia dura debería haber aprendido en doctorado: llevar un diario de todas las investigaciones, ideas y especialmente las decisiones. Cuando decidiste usar ARIMA en lugar de GARCH, regístralo en el diario del laboratorio y describe por qué tomaste la decisión. En el futuro, las personas tienden a olvidar la lógica detrás de las decisiones, por lo que es importante registrarlas. Desafortunadamente, las personas con antecedentes en ciencias sociales no tienen la costumbre de llevar los diarios de laboratorio, es un problema.

Otro aspecto de las buenas prácticas es la disciplina en la etapa inicial de puesta en servicio. Esto podría incluir cosas básicas como acordar por escrito lo que requiere el comisionado (para evitar malentendidos y disputas posteriores) y aclarar quién en el negocio tiene autoridad para comisionar el trabajo (un primer paso para garantizar que la función aborde las necesidades comerciales reales y no solo complacer a cualquiera que tenga una idea brillante).

La disciplina en la puesta en servicio también debe promover un diálogo constructivo antes del acuerdo sobre el trabajo a realizar. Los encargados pueden tener una idea vaga de lo que necesitan pero tienen dificultades para formularlo con precisión, o si ofrecen una formulación precisa, puede que no sea lo más relevante para sus necesidades comerciales (por ejemplo, podrían solicitar una investigación de las razones de una caída en las ventas a corto plazo, cuando lo que realmente les interesa son los factores a más largo plazo que impulsan las ventas). Los estadísticos e investigadores pueden ser buenos para formular preguntas precisas o planes de trabajo, pero menos capaces de identificar lo que será útil para el negocio. Hay un paralelo con buenas prácticas en investigación académica que hace una distinción entre preguntas de investigación.identificando temas de interés bastante amplios e hipótesis y objetivos de investigación dentro de dichos temas que son lo suficientemente específicos como para conducir a estudios de investigación bien definidos. Por lo tanto, puede ser útil pensar que los comisionados generan el equivalente de las preguntas de investigación y que los estadísticos e investigadores los ayudan a identificar programas de trabajo más específicos relevantes para esas preguntas.

Creo que ha recibido parte de su respuesta en la pregunta: una "buena estructura" es clave.

Soy ingeniero y he estado trabajando en roles que enfatizan una aplicación similar, donde se le presentan problemas para brindar asistencia con el análisis y la mejora de los resultados, pero tiene un rol de asesor en lugar de implementador.

Los mejores enfoques, que he visto, son los que no son demasiado prescriptivos o flexibles para garantizar la cantidad correcta de evidencia de que el trabajo se realizó con diligencia, que es lo que creo que está buscando.

Six Sigma (que es un término un poco sucio en algunos lugares en los que he trabajado) y otras metodologías proporcionan un marco para abordar, resolver e incorporar una solución. Debido a que se basan en un marco, pueden ser auditados. La clave es asegurar que todos estén capacitados en la metodología Y tener una buena plantilla que sea auditable.

Por ejemplo, es probable que desee que las soluciones sean de un estándar: esto no está definido por el programa utilizado, sino más bien si puede auditar los pasos de análisis utilizados en una fecha posterior y estar seguro de que la tarea se completó según un estándar. Proporcionar hitos, por ejemplo, los puntos de verificación donde puede auditar será más fácil que intentar auditar al final del proyecto.

Volviendo a Six Sigma, algunos enfoques podrían ser auditar en la etapa de definición, después de medir y analizar, y finalmente en la conclusión (después de mejorar y controlar).

Six Sigma ciertamente no es el mejor en todas las situaciones, pero puedo recomendarlo como un posible punto de partida.