二つのチームが同じ活動を異なる方法で数えていても、計算ミスとは限りません。一方は今週に予定されている予約を、もう一方は今週に完了した予約を報告しているかもしれません。会議ではどちらも「週間予約数」と呼ばれかねません。共通の指標定義があれば、この曖昧さを業務側で確認できる判断事項に変えられます。データとデザインのチームにとっても、実装・テストする具体的な対象になります。
このページの内容
ダッシュボードを業務上の判断と結びつける
誰が情報を使い、何を判断し、どの頻度で必要とするかを確認します。人員配置の計画には今後の需要が必要であり、提供済みサービスの振り返りには完了した活動が必要です。異なる問いであり、指標も分ける必要があるかもしれません。同等の別期間との比較など、数値の意味を判断できる比較対象を定めます。また、合計が変わった際に利用者が必要とする詳細も特定してください。これにより、チームの問いに答えない見栄えのよいグラフだけが増えるのを防げます。
- 対象の利用者と判断内容を明記します。
- 今後の需要と完了した業務を分けます。
- 集計期間と有用な比較対象を定めます。
定義を書き、サンプルレコードで確認する
指標の例：「今週完了した予約」は、予定開始日時が合意した現地時間の週内にあり、現在のステータスが完了である予約レコードを数えます。キャンセル、無断欠席、これから実施する予約は含めません。サンプルが12件あり、完了8件、キャンセル2件、無断欠席1件、今後の予約1件なら、結果は8件です。これは予約の件数であって、重複を除いた顧客数ではありません。同じ顧客が2回来ていたなら、ユニーク顧客数は別の問いに答える指標です。この区別を業務責任者に承認してもらいます。
- データソース：合意した予約データセット。
- 時刻のルール：事業のタイムゾーンで予約の予定開始日時を使用します。
- 週の境界：選んだ開始曜日と、開始を含み終了を含まない区間を明記します。
- 訂正のルール：後日のステータス変更によって過去の集計値を更新するかを定めます。
元データからレポートまでの経路を確認する
予約レコードがレポート用データセットに届くまでの流れを追います。取り込みで重複が発生する可能性はありますか。日次更新の後にステータス変更が届くことはありますか。どの項目が欠ける可能性がありますか。定義に合った確認を合意してください。この例では、安定した予約識別子、有効な予定日時、認識できるステータスが重要です。チェックに失敗した場合、問題を表示するのか、説明付きで該当レコードを除外するのか、訂正まで待つのかを決めます。不完全なデータ連携を黙って完全なものと扱わず、担当者を決めてください。
- サンプルの集計値を元レコードと照合します。
- 本当のゼロとデータ未取得を区別します。
- 想定する更新時刻を記録し、更新の遅れを調べます。
画面上で数値を説明できるようにする
指標には正確な名称を付け、集計期間と直近の正常更新を表示します。合計の近くに短い定義を添え、権限の範囲内で関連レコードを確認できるようにしてください。フィルターで集計対象が変わるなら、有効なフィルターを見えるようにします。想定利用者に、例の結果が八になる理由と、後から完了に変わった場合に値が変わるかを説明してもらい、ダッシュボードを検証します。答えるために分析担当者が隠れたルールを組み立て直さなければならないなら、定義か表示をさらに改善する必要があります。