ビジネス環境での統計分析のグッドプラクティス

（これは厳密に統計に関するものではないことを理解していますが、ビジネス環境での統計の普及に関するものであるため、CVのトピック範囲内にあると想定しています）

背景の簡単な説明：

私たちのビジネス環境（および他の環境が疑われる）には、統計分析と研究に特化したサポート機能があります。私たちはビジネスインテリジェンスと緊密に連携しており、他の部門から委託されて作品を制作しています。実際には、データ、分析、結論は私たちのものではありません。データを収集し、分析を実行し、コミッショナーが作業で使用する結論を導き出します。

私がやりたいこと：

現在、私たちはかなり自由放任的なアプローチを実行しています。サポート機能の個人は、作業の委託、データの収集（または、存在する場合はBusiness Intelligenceによる抽出）、分析、および最終的な結論のセットが委託者に送信されるときに割り当てられます。これは、分析を読むことが委員の役割ではないという根拠に基づいて大まかに正当化されています。コミッショナーが調査したい質問/トピックに適切な分析を提供することを保証するのは、サポート機能としての私たちの役割です。

アプローチについてもう少し構造を呼び出して、

a）高品質の分析。

b）分析が不適切な決定につながる可能性がある場合、防御力を提供します。そして、作ります

c）分析がより透明であるため、データを取得して結果を出力する「ブラックボックス」とは見なされません。

私の最初の考えは次のとおりです。

1. 取られたアプローチ、行われた仮定、見つかった問題、存在する不確実性などを正当化するすべての作業を含む技術文書を作成します。これは必ずしもすべての人が読む必要はありませんが、説明する手段として使用する必要がありますコミッショナーが導き出した結論を使用した結果。これにより、リスクの一部が属するべきと思われる場所、つまりコミッショナーに移されます。

2. すべての分析をStata、SPSS、Rなどのパッケージに制限し、技術文書とともにコードの完全なセットを作成する必要があります。私たちは皆、ある種の分析にMicrosoft Excelを使用する習慣があります（何よりも悪い習慣）。ただし、Excelは分析の容易な再現性を促進しません。これは、分析が疑問視されたときにサポート機能を保護するのに役立ち、アプローチの透明性を作成しますが、（3）の役割をはるかに簡単にします：

3. レビューアを、コミッショナーに送信する前に「副署名」する必要があるすべての作品に割り当てます。副署することにより、分析の整合性を2人に分散し、2人が協力することを奨励します（2人のヘッドが1人よりも優れています）。これにより、分析の品質が向上し、ある程度の防御力も得られます。

この種のビジネス環境に適用できるグッドプラクティスの他の側面はありますか？

2つの言葉での私のアドバイス（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関連）は、ビジネスプロセス、組織単位、文化、および人を含むビジネスアーキテクチャと整合する必要があります。これが役立つことを願っています。

更新：新規または既存のデータ分析アーキテクチャ（エンタープライズアーキテクチャ用語ではデータアーキテクチャとも呼ばれます）の作成に関して、これら2つのプレゼンテーションスライドのセット（thisとthis）も役立つと思いました。

銀行業務では、モデリングはOCC 2011-12などのモデルリスク管理ガイドラインに準拠する必要があります。あなたが銀行にいなくても面白いドキュメントだと思います。

MathWorksには、モデリング標準に関するこの記事があります。

モデリングには何らかの形でソフトウェアを書くことが含まれるため、特にテストや単体テストに関しては、ソフトウェア開発方法論の要素を使用します。SVNなどのソフトウェア構成管理ツールも採用しています。問題追跡システムやCMSなどの複雑なソフトウェアプロジェクトの管理に関して、モデリングチームはプログラマーから多くのことを学ぶことができます。

最も重要なことの1つは、方法論とプロセス、モデル開発ライフサイクルです。モデルの開発方法のガイドラインを作成し、それらをテストし、標準ツールとテストなどをリストします。たとえば、1つまたは2つの適合度テストを選択し、どこでも使用します。

モデリングスクリプト、ホワイトペーパー、プレゼンテーションなど、すべてのテンプレートを作成します。たとえば、すべてのドキュメント用にLaTeXのテンプレートがあるので、ホワイトペーパーは非常に似ており、誰もが情報を探す場所を知っています。記述統計などの標準セクションと、尖度、最初と最後の観測日などの標準列があります。

ラボジャーナルを用意します。これは、ハードサイエンスの人々が博士号で学ばなければならないことの1つです。すべての研究、アイデア、特に意思決定の日記をつけることです。GARCHの代わりにARIMAを使用することに決めた場合は、ラボジャーナルに記録し、その決定を下した理由を説明してください。将来、人々は決定の背後にある理論的根拠を忘れがちなので、それらを記録することが重要です。残念ながら、社会科学のバックグラウンドを持つ人々は、研究室のジャーナルを保持する習慣がありません。これは問題です。

優れた実践のもう1つの側面は、最初の試運転段階での規律です。これには、コミッショナーが必要とするものを書面で合意すること（誤解やその後の紛争を回避するため）のような基本的なことや、業務の委任権限をビジネス内の誰が持っているかを明確にすること（機能が実際のビジネスニーズに対応しており、明るいアイディアを持っている人ならだれでも楽しんでください）。

試運転の規律は、実施する作業について合意する前に建設的な対話を促進すべきです。それらのコミッショニングは、必要なものについて漠然としたアイデアを持っているかもしれませんが、それを正確に定式化するのが困難であるかもしれません。彼らが本当に興味を持っているのが売り上げを促進する長期的な要因であるとき、売り上げが短期的に落ち込む理由です。統計学者や研究者は、正確な質問や作業計画を立てるのは得意かもしれませんが、ビジネスに役立つものを特定することはできません。研究の質問を区別する学術研究の優れた実践と並行することをお勧めします関心のあるかなり広いトピックを特定し、明確に定義された調査研究に導くのに十分な特定のトピック内の研究仮説と目的を特定します。したがって、コミッショナーが研究の質問に相当するものを生成し、統計学者と研究者がそれらの質問に関連するより具体的な作業プログラムを特定するのを助けると考えると役立つかもしれません。

あなたは質問の答えの一部を手に入れたと思います-「良い構造」が鍵です。

私はエンジニアであり、同様のアプリケーションを強調する役割で働いています-あなたは結果の分析と改善を支援するために問題を紹介されますが、実装者の役割ではなく助言者です。

私が見た最高のアプローチは、仕事が勤勉に行われたという適切な量の証拠を確保するためにあまりにも規範的でも緩いものでもないものです-これはあなたが望んでいることです。

シックスシグマ（私が働いたことのある場所では少し汚い用語です）と他の方法論は、ソリューションにアプローチし、解決し、埋め込むためのフレームワークを提供します。フレームワークに基づいているため、監査できます。重要なのは、全員が方法論のトレーニングを受け、監査可能な優れたテンプレートを持っていることを確認することです。

たとえば、ソリューションを標準にすることをお勧めします。これは使用するプログラムによって定義されるのではなく、後日使用される分析手順を監査して、タスクが標準に完了したことを確認できるかどうかです。マイルストーンの提供-たとえば、監査できるチェックポイントは、プロジェクトの最後に監査しようとするよりも簡単です。

シックスシグマに戻ると、メジャーと分析の後、最終段階（改善と制御の後）で最終段階で監査するというアプローチがあります。

シックスシグマは確かにすべての状況で最適というわけではありませんが、潜在的な出発点として推奨できます。