在业务环境中进行统计分析的良好做法

（虽然我意识到这不完全是统计信息，而是有关在业务环境中分发统计信息，所以我认为统计信息仍在CV的主题范围内）

简要背景：

我们的业务环境（我怀疑其他环境）具有支持功能，专门从事统计分析和研究。我们与商业情报部门紧密合作，并受其他部门的委托进行工作。实际上，数据，分析和结论不属于我们：我们收集数据，进行分析并得出结论，以供专员在其工作中使用。

我想做的事：

目前，我们采用放任自流的方式。在调试工作时，将分配支持功能中的个人，由商务智能收集（或提取数据，如果有的话），进行分析，并将最终结论发送给专员。松散的理由是，通读分析不是专员的职责；确保支持我们对专员要探讨的问题/主题提供正确的分析是我们的支持职能。

我想在制作方法上调用更多的结构

a）我们对更高质量的分析；

b）当我们的分析可能导致错误的决定时提供辩护；和做

c）我们的分析更加透明，因此我们不会被视为收集数据并吐出结果的“黑匣子”。

我最初的想法是：

1. 制作包含每项工作的技术文档，以证明所采用的方法，所作的假设，发现的问题，存在的不确定性等。尽管不一定所有人都可以理解，但应将其用作解释以下内容的方法：专员使用得出的结论的后果。这会将一些风险转移到感觉应该属于的地方：委托人。

2. 将所有分析限制在一个软件包中，例如Stata，SPSS或R，并要求在技术文档的旁边生成一整套代码。我们所有人都有使用Microsoft Excel进行某些类型的分析的习惯（坏习惯比什么都重要）。但是，Excel不能促进分析的简单可重复性。这有助于在质疑我们的分析时捍卫支持职能，在我们的方法中建立透明性，而且使（3）的角色更加容易：

3. 为每件必须分配“签核”工作的作品分配一位审稿人，然后再将其发送给专员。通过加签，它将分析的完整性分配给2个人，并鼓励他们共同努力（2个负责人比1个负责任）。这将提高分析质量，并提供一定的辩护性。

在这种商业环境中是否还有其他可以应用的良好实践方面？

我的建议是两个词（TL； DR模式）：可重复的研究。

有关更多详细信息 -大多数情况下不再重复自己-让我介绍一下StackExchange其他地方的相关答案。这些答案代表了我对以下主题的想法（和一些经验）：

• 数据清理：https : //datascience.stackexchange.com/a/722/2452
• 可重复的研究：https : //datascience.stackexchange.com/a/759/2452
• 报告与仪表板：https : //datascience.stackexchange.com/a/907/2452
• 数据分析工作流程和EDA：https：//datascience.stackexchange.com/a/1006/2452
• 大数据和R：https : //datascience.stackexchange.com/a/780/2452

最后说明（对不起，如果您发现它很明显）：无论您的业务环境是什么类型（顺便说一下，目前尚不清楚），我建议从业务方面开始，并创建一个数据分析架构，所有与IT相关的方面）都应与业务架构保持一致，包括业务流程，组织单位，文化和人员。我希望这会有所帮助。

更新：关于创建新的或改进的现有数据分析体系结构（在企业体系结构术语中也称为数据体系结构），我认为这两套演示幻灯片也可能有用：this和this。

在银行业务中，建模必须遵守模型风险管理指南，例如OCC 2011-12。我认为即使您不在银行业，这也是一个有趣的文件。

MathWorks上有关于建模标准的文章。

由于建模涉及以一种或另一种形式编写软件，因此我使用软件开发方法论的要素，尤其是在测试和单元测试方面。我还采用了诸如SVN之类的软件配置管理工具。在管理复杂的软件项目（例如问题跟踪系统和CMS）方面，建模团队可以从程序员那里学到很多东西。

最重要的事情之一是方法论和过程，模型开发生命周期。创建有关如何开发模型，进行测试，列出标准工具和测试等的指南。例如，选择一个或两个拟合优度测试，并在各处使用它们。

创建所有内容的模板：建模脚本，白皮书，演示文稿等。例如，我在LaTeX中拥有所有文档的模板，因此我们的白皮书看起来非常相似，每个人都知道在哪里寻找信息。我们有标准部分，例如描述性统计数据，并且在其中包含标准列，例如峰度，第一个和最后一个观察日期等。

有实验室日记。这是硬科学界人士应该在博士学位中学到的一件事：记下所有研究，构想，尤其是决策的日记。当您决定使用ARIMA而不是GARCH时，请将其记录在实验室日志中，并说明做出该决定的原因。一路走来，人们往往会忘记决策背后的理由，因此记录决策很重要。不幸的是，来自社会科学背景的人们没有养成实验室日记的习惯，这是一个问题。

良好做法的另一个方面是在初始调试阶段的纪律。这可能包括一些基本的事情，例如以书面形式同意专员的要求（以避免误解和随后的纠纷），并澄清业务中谁有权委托工作（迈向确保职能满足实际业务需求而不是满足职能的第一步）。放纵任何有好主意的人）。

在就将要开展的工作达成协议之前，调试纪律还应促进建设性对话。这些调试可能对他们的需求含糊其词，但难以精确地制定，或者如果他们确实提供了精确的描述，则可能与他们的业务需求最不相关（例如，他们可能要求调查短期内销量下降的原因，而他们真正感兴趣的是推动销售的长期因素。统计人员和研究人员可能会擅长提出精确的问题或工作计划，但不太可能确定对企业有用的内容。我建议在学术研究中与良好实践相提并论，以区分研究问题确定足够广泛的兴趣主题和研究假设，并在此类主题内确定目标，这些主题足够具体，可以进行明确的研究。因此，将专员视为产生与研究问题相当的事物可能是有益的，而统计学家和研究人员则可以帮助他们确定与这些问题相关的更具体的工作计划。

我认为您已经在问题中得到部分答案-“良好的结构”是关键。

我是一名工程师，并且一直在强调类似应用程序的角色中工作-在该角色中，您会遇到一些问题，以帮助您分析和改善结果，但他们是顾问而非执行者。

我所看到的最好的方法是，没有太多的规定或宽松的方法来确保有足够的证据表明这项工作是尽职尽责的，我认为这是您所追求的。

6西格码（在我工作过的某些地方这是一个肮脏的术语）和其他方法学提供了一种框架，用于接近，解决和嵌入解决方案。因为它们基于框架，所以可以对其进行审核。关键是要确保每个人都接受过方法学方面的培训，并拥有可审核的良好模板。

例如，您可能希望解决方案符合标准-这不是所用程序定义的，而是您是否可以审核以后使用的分析步骤，并确信任务已按标准完成。提供里程碑-例如，可以在其中进行审核的检查点比在项目结束时尝试进行审核要容易。

回到六西格码，一些方法可能是在“定义”阶段，“测量和分析”之后，最后在结论（“改进和控制”之后）进行审核。

当然，六西格码并不是所有情况下的最佳选择，但我可以推荐它作为一个潜在的起点。