ダッシュボードのカスタマイズに関するベスト プラクティス

はじめに

Insights のダッシュボードをカスタマイズする機能は、この製品の中核をなすものです。 KPI、フィルター、ウィジェットを特定のニーズに合わせて調整することで、組織の自動化プログラムとビジネス上のメリットをより正確に把握できます。 カスタム ダッシュボードは、Automation Hub に自動化プログラムのより統合されたビューを提供したり、Orchestrator の自動化によって節約された時間とお金を表示したりと、幅広い可能性を提供します。 このベスト プラクティスのセクションでは、組織にとって効率的で信頼性の高いカスタム ダッシュボードを作成する方法について説明します。

適切な Explore を使用する

Explore は、ダッシュボードの作成やカスタマイズ時に使用できるビュー、エンティティ、フィールドを駆動するデータ モデルの基礎を形成します。 新しいウィジェットを設計するときに目的のエンティティやフィールドが利用可能であることを確認しながら、全体的なパフォーマンスを向上させるには、適切な Explore を選択することが重要です。 たとえば、一定期間のキュー アイテムの数を集計するウィジェットを作成する場合は、[キュー] Explore を使用するのが最適です。 [キューの ROI] Explore のようなものを使用すると、ジョブと ROI に関連する情報が組み合わされるため、このコンテキストでは不要な結合が発生する可能性があります。

図 1. Explore を選択する

Explore について、および各ビューが Explore の下の場所にある場所については、「 データ モデル 」をご覧ください。

フィールドとメジャーを選択する

フィールドとメジャーを選択することで、組織は、利害関係者にとって最も重要な関連データを使用してレポートを強化することができます。 フィールドとメジャーを選択する際は、それらが [探索] 内の同じビューの一部であることを確認してください。 これにより、不要なデータ結合を最小限に抑えることができます。 たとえば、フォルダーごとのキュー アイテムの手動コストを集計する場合は、[ジョブ] ビューではなく [キュー] ビューのフォルダー フィールドを使用することをお勧めします。 複数のビューにまたがってフィールドやメジャーが必要な場合は、ウィジェットを分割することを検討してください。

図 2. [キュー] ビューの [フォルダー] フィールド

ウィジェットをシンプルに保つ

ウィジェットのデザインをシンプルに保つことは、Insights ダッシュボードにとって非常に重要です。 複雑なウィジェット、特にさまざまな Explore の複数のフィールドからデータを取得するウィジェットは、パフォーマンスと応答時間に影響を与える可能性があります。

たとえば、プロセスの実行回数に基づいて ROI を計算するプロセス ([プロセスの ROI]) や、処理されるキュー アイテムの数に依存するプロセス ([キューの ROI]) があります。 このような場合は、2 つの ROI フィールドを組み合わせることができます。 ただし、複雑なデータ結合が作成され、特にデータセットが大きい場合には、応答が遅くなる可能性があります。 このパフォーマンスへの影響は、データベースのパフォーマンスが制限される可能性があるオンプレミスのデプロイで特に顕著です。

このような問題が発生した場合は、次のアクションがパフォーマンスの向上に役立ちます。

• ウィジェットのデータ範囲を制限します。
• データベースの仕様を増やします (オンプレミス インスタンスにのみ適用)。
• ウィジェットが主に電子メールで送信されるレポートで使用する場合は、次の 2 つのダッシュボードを使用できます。
  • 両方のフィールドを組み合わせたメール レポートの生成に使用するダッシュボードです。 ここでは、メール レポートはインタラクティブではないため、パフォーマンスの低下はあまり問題になりません。
  • 日常的に使用するために、パフォーマンスが最適化された独立したダッシュボードで、フィールドを 2 つの異なるビジュアライゼーションに分割します。 このダッシュボードは対話型の使用を想定して設計されているため、応答時間の短縮が優先されます。

ウィジェット数

含めるウィジェットの数は、組織のカスタム ダッシュボードを設計する際に大きな影響を及ぼします。 追加するウィジェットが多すぎると、ダッシュボードの読み込みに数分かかる場合があります。 同時に、提供するウィジェットが少なすぎると、ユーザーが価値を得てアクションを実行するための KPI やビジュアライゼーションが不十分になる可能性があります。

ダッシュボードには 10 個から 15 個のウィジェットを含めることをお勧めします。 この範囲は、パフォーマンスと教育的価値のバランスを取るのに役立ちます。 データ集約型のウィジェットであっても、ダッシュボードはスムーズかつ効率的に機能する必要があります。 さらに、さまざまなKPIとデータソースが可能になり、メトリックの包括的で有益なビューが促進されます。

ダッシュボードについて詳しくは、「 ダッシュボード」 をご覧ください。

フィルター

ダッシュボード フィルターとウィジェット フィルターは、ユーザーがデータを効果的にセグメント化できるようにするために重要であり、特定のユース ケースに合わせて最も重要なメトリックのカスタマイズされたビューを提供します。 フィルターは、最も関連性の高い情報に的を絞ることで意思決定を強化し、すべてのロボット、プロセス、リージョン、事業部門で効率的なパフォーマンスを強化できます。

ダッシュボードの読み込み時間が長くなる場合は、ダッシュボードの日付範囲を狭めることをお勧めします。 このアクションにより、パフォーマンスが向上し、ウィジェットが計算されるデータの量を減らすことができます。 さらに、特定のウィジェットが他のウィジェットよりも問題が多いことが判明した場合は、ウィジェットレベルの日付フィルターを適用してウィジェットのパフォーマンスを向上させます。

図 3. フィトラーの追加

フィルターについて詳しくは、「 ダッシュボード」をご覧ください 。

手記： フォルダーのフィルタリングにより、パフォーマンスが大幅に低下することがあります。 必要に応じて、フィルターの取り外しを検討してください。

カスタム変数を使用する

カスタム変数を使用すると、組織はプロセスやキュー アイテムの実行に関するより具体的な詳細を送信できます。 この強化されたデータは、傾向、ボトルネック、または改善が必要な領域を特定するのに役立ち、組織全体でより多くの情報に基づいた意思決定をサポートします。

カスタム変数は、Insights にカスタム データをインポートする場合に推奨される方法であり、ロボットのログ メッセージを介してビジネス情報/データを送信する代わりに使用する必要があります。 ビジネス データのロボット ログのメッセージ フィールドを送信すると、クエリで検索する必要があるログの量が大量になるため、パフォーマンスが低下し、ダッシュボードの読み込み時間が長くなる可能性があります。

図4. カスタム変数を設定する

カスタム変数について詳しくは、「 カスタム変数 」をご覧ください。

オンプレミスのヒント

データベース アカウントにクエリを終了する権限があることを確認します。 これには、アカウントに sysadmin 権限または任意の接続の変更権限が必要です。 この設定を使用すると、ユーザーがセッションを閉じたりページの読み込みをキャンセルしたりした場合に Looker で SQL クエリを終了できるため、パフォーマンスが向上します。 たとえば、読み込みが遅いときにページを再読み込みするのが一般的です。 リロードのたびにリクエストがキューに入れられ、クエリを終了するために必要な権限がないと、リロードのたびに問題が悪化する可能性があります。

問題を調査したり、ダッシュボードを作成したりするときは、データを減らします。 たとえば、3 年分のデータをクエリするレポートを作成する場合、過去 30 日間のデータなど、より小さなデータ スケールに対してクエリを実行すると、ダッシュボードの作成またはデバッグが管理しやすくなります。

デバッグ時には、問題が発生する可能性のあるウィジェットを専用のダッシュボードに再配置することを検討してください。 ダッシュボード全体の問題は、実際には 1 つのウィジェットに起因している可能性があります。 したがって、そのウィジェットを分離すると、問題を正しく特定して対処するのに役立ちます。