実装ガイド › ケース スタディ例 › データ モデリングの例 › ケース スタディ 8： ヘルプデスクの能力

ケース スタディ 8： ヘルプデスクの能力

これはヘルプデスクの能力の典型的なケース スタディです。

データ ソースが以下のように与えられているとします。

上記のデータ ソースには、顧客がサービスを提供するさまざまなロケーションで各顧客用に管理されるヘルプデスク チケットの詳細がリスト表示されています。 単一のロケーションが顧客間で共有される場合もあります。

このデータ ソースを使用してレポートするためには以下の 3 つの要件が必要です。

• 顧客 CM3 に対し 4 時間以内に解決した優先度 1 チケットの割合（%）。
• 各場所の顧客 CM3 に対し 4 時間以内に解決した優先度 1 チケットの割合（%）。
• 各場所の顧客 CM3 に対し 1 日以内に終了した優先度 1 チケットの割合（%）。

上記の要件は、イベントが次の項目によってフィルタされる必要があることを示しています。

• 優先度
• 顧客
• 場所

これらのフィルタ基準のどれがイベント タイプとして変換され、どれが関連リソースとして変換されるのか、指定する必要があります。

イベント タイプの選択方法

必要とされる 3 つのフィルタ条件のうち、以下のような理由で、イベント タイプに翻訳されることが最も適切なのはチケット優先度です。

• 処理されている（優先度 1 チケット）イベントの種類を説明していること。
• 存在する優先度の数が比較的少ない（優先度 1、2、3）こと。
• イベント タイプ自体は比較的一定（ヘルプデスクはチケットを処理する優先度をめったに変更しません）なこと。

リソースの選択方法

必要な他の 2 つのフィルタ基準は顧客と場所で、これらはレポートが必要な最も小さなエンティティです。 そのため、顧客と場所の組み合わせはリソースです。

顧客と場所は比較的固定されたエンティティで、明確なライフ サイクルを持っています。それによって新しい顧客または新しいサイトが追加される場合があります。 さらに、サイトと顧客の関係は変化する場合があります。

変換のために、データ ソースから複数のフィールドを使用することが可能です。 前のケース スタディでは、サーバ フィールドは CA Business Service Insight リソースに翻訳されましたが、この場合、リソースは 2 つのフィールドの組み合わせを使用して構築されます。 そのため、それぞれの並べ替えは新規リソースを作成します。

リソース リストを以下に示します。

出力リソースは、顧客フィールドとサイト フィールドを '+' 記号で組み合わせたものです。 データ ソースから抽出され、後にレポートに表示されるので、リソースの名前を意識しておくことは重要です。 レポート機能は期待に応える必要があります。

注： ヘルプデスクまたは任意のチケットまたはインシデント システムをモデル化するときによく見られる誤りは、単一のインシデントをリソースとして定義することです。

以下の正しくない仮定が誤りに結びつくことがよくあります。

1. 単一のインシデントは、レポートされるインシデントです。単一のインシデントが顧客サイトの計算の基礎とならないように、エンティティを、計算が生成される対象のエンティティとしてレポートされるように設定しません。 一般的に、SLA は総合的業績に基づいており、個々がチケットを処理する能力に基づくのではありません。
2. 保証はチケット レベル別です。 保証は定期的なものなので、これは誤りです。計算されるのは、時間経過に伴う総計です。

リソースに対する配置の設定

最初の計算要件として、以下の内容があります。

1. 顧客 CM3 に対し 4 時間以内に解決した優先度 1 チケットの割合（%）。
   • 特定の顧客のせいにされるチケットのイベントを受診する必要があります。 顧客はこのリソースの一部で、また顧客サイトを示しています。 そのため、リソースに関連し、その顧客に起因するイベントすべてをキャプチャするには、2 つのオプションがあります。
   • データ ソース中の顧客が契約関係者を代表する場合は、そのリソースは関連する契約関係者に添付できます。 これにより、契約関係者に関する登録が可能になります。 可能な限り、これは常に好ましいことです。
   • データ ソース中の顧客それぞれに対するリソース グループを作成し、その内部の関連リソースすべてをグループ化します。 この方法を使用して、そ登録はリソース グループ別に行われます。

   次の 2 つの計算要件について検討します。

2. 各場所の顧客 CM3 に対し 4 時間以内に解決した優先度 1 チケットの割合（%）。
3. 各場所の顧客 CM3 に対し 1 日以内に終了した優先度 1 チケットの割合（%）。

これらの要件については、リソースをリソース グループに集めます。サイトごとに別々に計算が必要だという前提で、メトリックはクラスタ化する必要があるためです。

注： 現在のモデルおよび要件用のリソースの配置が必要でなくても、将来の要件に配慮して作成しておくことは重要です。 そうすることにより、将来のシステム開発でのオーバヘッドの発生を防止します。

Timestamp フィールドの選択

以前言及したように、Timestamp は相関エンジンがイベントを処理する方法にとって非常に重要です。 メトリックは常に期間あたりのサービス レベルを計算し、この期間内に処理されるイベントは、そのタイムスタンプがその期間内にあるものです。

最初のケース スタディでは、データ ソースには時間のフィールドが 1 つしかありません。 ただし、この場合、タイムスタンプとして設定可能な 3 つのフィールドがあります。 最初の 2 つのレコードの検討

解決時間を計算するには、発生日時および解決日時の両方が必要です。 イベントとしては、1 つのタイムスタンプのみを添付することができます。 その後、他方は、値フィールド内の値として使用できます。

発生日時の値がタイムスタンプとして使用される場合、チケットは 12 月の結果に含まれています。 「解決日時」の値がタイムスタンプとして使用される場合、チケットは 1 月の結果に含まれています。 どちらの選択肢も有効です。 選択内容は、チケットがレポートのどこに表示される必要があるかについて期待に応える必要があります。

それによってイベントがいつ計算に使用されるかが決まるので、実装にあたって非常に重要な点です。 たとえば、チケットは 11 月に発生するが、12 月まで終了しない場合、いつ SLA の結果に貢献する必要がありますか。 11 月のデータに含めますか、それとも 12 月でしょうか。

この場合、チケットがデータ ソースにレポートされるのはクローズされてからのみなので、データがキャプチャされるのはチケットがクローズされてからのみです。 通常、クローズされた日付は発生日時および解決日時のどちらよりも後の日付になります。 発生日時がタイムスタンプとして選択された場合は、12 月の結果の一部として処理される必要があります。 終了日付は 1 月でしたから、このチケットが報告されたときにはすでに 12 月は過ぎていたことになります。 従って、12 月の結果はすでに発行済みです。 その後、相関エンジンは、タイムスタンプが 12 月であることから過去のイベントであることに気づき、再計算をトリガします。 そのため、12 月の結果にさかのぼって変更されます。

どの時間フィールドがタイムスタンプとして選択される必要があるか定義できるためには、これらの結果を完全に理解する必要があります。 通常、クローズ日付は、遡及して変わらない最終レポートを持つために選択されます。

他方、タイムスタンプとしてクローズ日付を使用することは、チケットが計算に入るのを遅らせます。 解決されたチケットは、相当な時間経過後にのみクローズされる場合があります。

ただし、このクローズ日付の利用は、組織内でチケットの終業時間を早めるプロセスのトリガとなる場合があることにも注意する必要があります。

したがって、最終提案は次のようになります。