---
sourceDocument: Xanadu プラットフォームアナリティクス
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/ja-JP/xanadu/now-intelligence

 Release :

    - xanadu

ft:locale :

    - ja-JP

ft:publication_title :

    - Xanadu プラットフォームアナリティクス

ft:clusterId :

    - par

bundleId :

    - par

workflow :

    - Platform


---

# 改善の機会の例

# 改善の機会の例 {#ariaid-title1}

* リリースバージョン: Xanadu
* 
* 更新日 2024年08月01日
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 所要時間：3分

検索定義のユースケースを以下で説明します。

ユースケース 1a:グループ間でのレコードのバウンスアナリストは多くの場合、特定のグループ (サービスデスクなど) から送信されたレコードを特定し、別のグループに再アサインし、最終的に最初のグループによって再度解決されたレコードを特定したいと考えます。  
最初のグループがわかっている場合は、メッセージとカテゴリの検索ルールを使用します。

* 開始条件テーブル構成:インシデント
* 開始条件
  * 名前:グループ名 (Service Desk など)
  * 条件タイプ:フィールド/値条件
  * フィールド = アサイン先グループ
  * 述語 = 次の値に等しい
  * フィールド値 = サービスデスク
  * 一致する発生件数:最初のみ
  {#finding-definition-examples__ul_hcd_x2d_jvb}
{#finding-definition-examples__ul_e3s_m2d_jvb}  
関係:最終的に次が続く

* 終了条件テーブル構成:インシデント
* 終了条件
  * 名前:グループ名 (Service Desk など)
  * 条件タイプ:フィールド/値条件
  * フィールド = アサイン先グループ
  * 述語 = 次の値に等しい
  * フィールド値 = サービスデスク
  * 一致する発生件数:最後のみ
  * 追跡期間:true
  {#finding-definition-examples__ul_lx3_2gd_jvb}
{#finding-definition-examples__ul_kpz_bgd_jvb}

ユースケース 1b:類似した初期グループを持つグループ間でバウンスするすべてのレコードを特定する必要がある場合は、メッセージとカテゴリの検索ルールを使用します。  
* 開始条件テーブル構成:インシデント
* 開始条件
  * 名前:アサイン先グループはすべて
  * 条件タイプ:フィールド/値条件
  * フィールド = アサイン先グループ
  * 述語 = すべて
  * 一致する発生件数:最初のみ
  {#finding-definition-examples__ul_sg2_13d_jvb}
{#finding-definition-examples__ul_pwx_ct5_fyb}  
関係:最終的に次が続く

* 終了条件テーブル構成:インシデント
* 終了条件
  * 名前:アサイン先グループはすべて
  * 条件タイプ:フィールド/値条件
  * フィールド = アサイン先グループ
  * 述語=は何でも
  * 一致する発生件数:すべて
  * 追跡期間:true
  * 関係制約:同じアサイン先グループを持つ
  {#finding-definition-examples__ul_y1f_v3d_jvb}
{#finding-definition-examples__ul_ord_33d_jvb}

ユースケース 2:SLA 違反SLA 違反が発生したときにステータスが \[新規\] であったすべてのレコードを表示します。  
検索定義にメッセージとカテゴリを指定した後、次のように検索ルールを指定します。

* 開始条件テーブル構成:インシデント
* 開始条件
  * 名前 = state
  * 条件タイプ:フィールド/値条件
  * フィールド = 都道府県
  * 述語 = 次の値に等しい
  * フィールド値 = 新規
  * 一致する発生件数 = 最初のみ
  {#finding-definition-examples__ul_i2f_1h4_fyb}
* コンテキスト条件:
  * 名前 = SLA 違反
  * Finding Def = 検索定義メッセージを追加します
  * 条件タイプ = コンテキストフィールド/値条件
  * Field=SLA 達成 (プロジェクトでアクティビティ定義として SLA が定義されていることを確認してください)
  * Predicate=is not (述語=ではない)
  * フィールド値 = true
  {#finding-definition-examples__ul_l5z_pj4_fyb}
* 関係:直行
* 終了条件テーブル構成:インシデント
* 終了条件
  * 名前:都道府県
  * 条件タイプ:フィールド/値条件
  * フィールド = 都道府県
  * 述語=is
  * フィールド値 = 対応中
  * 一致する発生件数 = 最初のみ
  {#finding-definition-examples__ul_qdy_tk4_fyb}
* コンテキスト条件:
  * 名前 = SLA 違反
  * 条件タイプ = コンテキストフィールド/値条件
  * Field=SLA 達成 (プロジェクトでアクティビティ定義として SLA が定義されていることを確認してください)
  * 述語=is
  * フィールド値 = true
  {#finding-definition-examples__ul_djd_yk4_fyb}
* 追跡期間:true

{#finding-definition-examples__ul_u4x_yg4_fyb}

ユースケース 3:親ステータスが \[対応中\] になってからタスクが作成されるまでの時間が 6 時間を超えている。解決時間またはレコードは、多くの場合、1 つ以上のタスクの完了に依存します。したがって、メイン レコードの解決時間を改善するには、メイン レコードが 対応中 ステータスに達した後、できるだけ早くタスクを開始することが重要です。この例では、ユーザーは、メインレコードが \[対応中\] になってから基になるタスクの作成に 6 時間以上かかったすべてのレコードを検索したいと考えています。検索定義にメッセージとカテゴリを指定した後、次のように検索ルールを指定します。

* 開始条件テーブルの構成:インシデントなどの親
* 開始条件
  * 名前:対応中の最初の発生
  * 条件タイプ:フィールド/値条件
  * フィールド = 都道府県
  * 述語 = 次の値に等しい
  * フィールド値 = 対応中
  * 一致する出現件数:first、only
    * 関係:最終的に次が続く
    * 終了条件テーブルの構成:インシデントタスク
    * 終了条件
      * 名前 = incident task start
      * \[条件タイプ\] = \[プロセスの開始\]
        * 制約:最小期間は 6 時間です
        * 追跡期間:true
        {#finding-definition-examples__ul_ihn_nrd_jvb}
      {#finding-definition-examples__ul_wrm_lrd_jvb}
    {#finding-definition-examples__ul_nrg_3rd_jvb}
  {#finding-definition-examples__ul_z1w_crd_jvb}

{#finding-definition-examples__ul_dpr_1rd_jvb}