データディクショナリ:方法とベストプラクティス

データディクショナリは、重要な用語とメトリックのリスト、定義、ビジネス用語集です。それは単純に聞こえますが、ほとんど些細なことですが、ビジネスを調整し、混乱を取り除く能力は非常に大きい場合があります。実際、データディクショナリは、データチームがビジネスに提供できる最も価値のあるアーティファクトの1つである可能性があります。

ほとんどの企業には、チーム間で異なる方法で使用または解釈される概念、用語、またはメトリックが少なくとも1つあります。これが起こると、混乱が支配します。意思決定者は、データが示す内容と実行するアクションについて意見が一致しない場合があります。チーム間のレポートでは、一貫性のないビジネスロジックが原因で、同じデータソースの同じメトリックに対して異なる数値が表示される場合があります。チームは正しい定義について議論し、芝生を守ることさえできます。おそらく、その定義によって数字が良く見えるからです。これはビジネスには適していません。

データディクショナリが作成されると、すべてのスタッフが参照して同じページにアクセスできるドキュメントになり、新しいスタッフの登録が容易になります。また、ビジネスインテリジェンス(BI)チームには、これらのメトリックの実装に関する明確な要件があります。

明確にするために、ここでは、生のデータベーステーブルドキュメントも考慮していませんが、それも重要です。ビジネス用語とメトリックの上位レベルのリストです。ビジネス全体では、「ユーザー」、「収益」、または「取得コスト」をどのように考えていますか?誰もが同じ理解または「販売地域」、「平均出荷時間」、または「セッション」を持っていますか?目標は、カスタマーサービスエージェントなどの若くて非技術的なスタッフが、ビジネスの各セクションのセクションを読み、関連する用語を理解できるが、ビジネスロジックを把握するのに十分詳細かつ正確であることです。それらのメトリックの。

この投稿では、データディクショナリを取り巻くいくつかのベストプラクティスと、その作成方法のプロセスについて詳しく説明します。これは決して機能する唯一のプロセスではありませんが、少なくとも私にとっては機能しています。ここでは、BIチームがこのプロセスを推進していると想定しています。私の見解では、彼らはデータディクショナリとBIツールのメトリックの実装を所有している必要があります。

1.条件を収集する

最初のステップは、用語のリストをコンパイルすることです。つまり、BIチームは、ビジネスコンセプトとメトリックの名前(メジャー)のリストと、データのスライスとサイコロの方法(ディメンション)を含むスプレッドシートを作成する必要があります。これは困難に思えますが、1つのアプローチは、ビジネスチームごとにビジネスチームに行き、すべての標準レポートとダッシュボードのサンプルを調べることです。チャートのすべての軸ラベル、レポートテーブルの列ヘッダー、およびデータのピボット方法のディメンションをリストします。したがって、テリトリーごとの期間(一定期間)を示すレポートでは、「収益」と「テリトリー」という2つの重要な用語が生成されます。この段階では、定義ではなく用語名のリストをコンパイルしています。

出力は、チーム名、用語名、データタイプ、サンプル値または2つのリスト、およびおそらくその用語を使用したサンプルレポートへのリンクです。追加すると便利な追加の列は、これがディメンションであるかメジャーであるかを示す列(通常、メジャーよりもディメンションで一致している)と、真実のソースを指定する列です。

ステップ1:定義のない用語のリスト

財務指標、マーケティング指標、顧客サービス指標などのビジネス機能ごとにリストを整理およびグループ化します。また、多くの分野にまたがる一般的なディメンション(「年」、「product_id」、「国」など)を分割することもできますチームも自分のセクションに。

このリストは、おそらくあなたが期待するほど長くはありません。これは、チームが比較的少数のレバーを使用して追跡および最適化しようとするメトリックのセットが比較的少ない傾向があるためです。たとえば、オンラインマーケティングでは、キャンペーン、チャネル、費用、セグメント。

リスト、特にそのセクションを確認し、欠落している用語を追加するようビジネスチームに依頼してください。堅牢なダッシュボードとレポートのセットがある場合、おそらく包括的なリストがあります。そうでない場合、これは収集する価値のある追加の概念を提供します。

2.用語を定義する

BIチームは、定義の照合または作成を試みる際に最初のパスを作成する必要があります。

まず、既存のドキュメントから定義を引き出します。これは、ウィキ、アニュアルレポート、またはSQLクエリやExcelマクロなどの実際のコードからのものです。定義は明確かつ明確でなければなりません。定義を書き出すよりも単純な式(ARPU = total_revenue / number_subscribersなど)を表示する方が明確な場合は、それを表示します。一部の用語を相互参照する必要がある場合でも、ほとんどのスタッフは定義を理解できるはずです。

次に、チームと1つずつ座り、不足している定義を設定したり、定義を改良したりするための支援を求めます。 (空白であっても、間違っていても定義から始めてより良い進歩を遂げることができます。)これは、そのチーム内で何らかの合意が得られるまで、ある程度のやり取りが必要になる場合があります。また、メトリックの現在の計算方法に関する調査も必要になる場合があります。

重要なのは、「現在の定義は何ですか?」ではなく「これをどのように定義すべきか?」と聞かないことです。たとえば、これは、非常に複雑な定義を継承している場合に簡素化するチャンスです。理想的な定義が取得されると、データチーム、技術チーム、またはビジネスの他の部分に、定義されたとおりにそのメトリックを提供するという追加の圧力がかかります。

3.競合を特定する

これは重要なステップです。定義がチーム間で異なる用語を根絶します。

4.アライメントを取得する

チーム間で異なる条件については、関連するチームを同じ部屋に持ち込みます(そしてドアをロックします)。それらがどのように、なぜ異なるのかを話し合ってください。

この会議では、2つの結果のみで合意する必要があります。

* 1つのチームは、他のチームの定義を採用することに同意します。

*それらには異なる正当な理由があります。この場合、一方または両方の用語の新しい名前に同意します。

(両方のチームが定義を共通の定義に変更することに同意する3番目のオプションは可能ですが、そうではありません。)

名前は、あいまいさや混乱を避けるために必要な長さでなければなりません。 「community_adjusted_editba」がより適切で適切な用語であり、通常の「ebitda」と区別される場合は、より長く、より説明的な用語を使用します。目標は、混乱しないように簡潔にすることです。

5.サインオフを取得する

チームヘッドにサインオフしてもらいます。これは非常に重要です。 BIチームが用語を定義し、ビジネスチームがひそかに同意しないようにする必要があります。その場合、ビジネスはExcelで独自のロジックを実装するだけで、元の状態に戻ります。ドメインの専門家として、またそれらの指標に基づいてビジネス上の意思決定を行う人々として、それらのビジネスオーナーは完全に参加している必要があります。

Warby Parkerでは、共同CEOの助けを借りて、チームヘッドが特定の日付までにサインオフし、それを行うことを要求しました。チームヘッドは忙しく、データディクショナリは、たとえ価値を確認できたとしても、最優先事項とは思えないかもしれません。したがって、このトップダウンのサポートは非​​常に価値があることが判明しました。

6.公開

データディクショナリは、BIツールだけでなく、会社全体がアクセスできる単一ページのドキュメントとして公開します。これらの定義は、役員、アナリスト、意思決定者だけでなく、すべてのスタッフが広く理解し、採用する必要があります。したがって、可視性は非常に重要です。会社がWikiを頻繁に使用している場合は、そこに公開します。人々が期待する場所であるべきです。

概念的には、これらの用語は単一のシステムまたはデータソースから独立しているため、BIツールに関連付けられていません。ただし、可能な場合は、個々の定義もBIツールに組み込む必要があります。ツールがこれをサポートしている場合、ディメンションまたはメジャーの上にマウスを置くと、定義と例が表示されます。

これらの定義が複数の場所に表示される可能性があるため、データチームは、静的テーブルを手動で維持するのではなく、データベーステーブルやコードリポジトリなどの単一ソースからデータディクショナリを自動生成するよう努める必要があります。たとえば、Warby Parkerでは、データ辞書はJenkinsのジョブから生成されました。リポジトリが変更された場合、ドキュメント(すべてのデータドキュメント用の専用内部Webサイトまたは「データブック」)が再生成されました。

7.維持する

主要な指標は比較的安定している必要がありますが、指標の定義を変更する必要がある正当なビジネス上の理由があるかもしれません。その変更と新しい定義は、ビジネスチームからもたらされるべきです。ただし、変更を実装して伝達するには、データチームの支援が必要です。

BIチームは、変更が展開される前に変更の影響を評価する必要があります。たとえば、メトリックの古い定義と新しい定義の両方を含むメトリックを示すチャートを作成して、数値がどのように変化するかについての予想を設定します。

定義の変更を製品リリースのように扱います。定義の変更を事前に伝え、予想される内容を伝え、ドキュメントの下部にある変更ログなどを使用して、データディクショナリに変更を文書化します。

異なるシステムが同期しないようにしないでください。したがって、ドキュメントの自動生成が重要である理由。

上記のプロセスに従ってデータディクショナリを作成するのは簡単なことではありません。多くのスタッフのメンバー間の会話と調整が必要なため、おそらく数か月かかります。これは、BIチームによって推進および調整された大規模なチームの努力ですが、広範な買収、協力、および努力、そしてトップダウンの強化が必要です。

プロセスを少しずつ行うことはお勧めしません。たとえば、後日データディクショナリに資金を提供することを期待して、完全に完成したマーケティングデータディクショナリを作成しないでください。これにより、チーム間でそれらの(ステップ4)アラインメントの議論を行うのが難しくなり、実際の成果が得られます。また、シーケンシャルな性質により、蒸気を失いやすくなります。目標を達成するには、共通のサインオフ日を持つチーム間で同時に議論する必要があります。