ヘルプデスク/チケットシステムカテゴリツリーのベストプラクティス
ヘルプデスク/チケットシステムを構成したことがある人は、「適切な」チケットカテゴリの作成に関して同じ反復プロセスを経たことがありますか？
リビジョン1：
- インフラ
- サーバ
- Citrix
- Windows Server
- .。
- デスクトップ
- ウィンドウズ
- マック
- .。
- サーバ
- アプリケーション
- アプリ1
- 問題
- リクエスト
- アプリ2
- .。
- アプリ1
- ユーザー
- パスワードのリセット
- ロックアウトされ
- .。
各企業サイトに上記の機能があることに気付くまではすべてが良さそうなので、サイトインジケーターを階層に組み込んでみると、すべてが再び良さそうです。次に、ビッグボスがすべてのインフラストラクチャチケットをまとめて知りたいと思うことがありますが、16の異なるインフラストラクチャバケット（サイトごとに1つ）があるため、質問に簡単に答えることはできません。などなど。
根本的な問題は、静的な階層を使用して、本質的に多次元であるものをモデル化しようとしていることです。そして問題は、データのスライスとダイシングだけではありません。階層が「完全」であるほど、ヘルプデスクアナリストが各チケットを適切に分類するのが難しくなります（「サーバーですが、ニューヨークのオフィスにあるので、サーバーまたはニューヨークの下にありますか？」）同じ問題。リレーショナルデータベース用に存在していたため、最終的にキューブが作成されました。また、ブログ投稿用に存在していたため、最終的には投稿に複数のカテゴリのタグを付けることができました。タグ付けが答えですが、ほとんどのチケット追跡製品はこの概念をサポートしていないため、静的階層に戻ります。
このことを考えると、アナリストの生活を困難にすることなく、関連性を維持しながら、できるだけ広くなるように、人々がどのようにカテゴリ階層を作成したのかを知りたいと思います。
ありがとう
問題は、本質的に多次元であるものをエンコードするために1つのカテゴリフィールドのみを使用しようとしていることであると言うとき、あなたは正確に正しいです。他のディメンションには追加のフィールドが必要です。
IssueTrakを使用しており、標準のカテゴリ階層を利用できます。ただし、場所用の個別のフィールドもあるため、場所ごと、カテゴリごと、またはその両方でレポートと集計を行うことができます。特定のサイトでオンまたはオフにできる他のフィールドもあります。たとえば、必要に応じて場所を地域にロールアップし、必要に応じて場所や地域とは異なる名前を付けることができます。それらを使用したい場合は、部門をオンにすることができます。組織があります。アセットアイテムがあるため、たとえば、チケットをServer01に関連付けることができ、Server01には、レポートできる独自の特性セットを含めることができます。
繰り返しますが、さまざまなディメンションを階層にエンコードしようとするのは間違いだと思います。報告したいさまざまな種類の項目について、個別のフィールドが必要なようです。
私の役に立たない答えは、タグを差し控えるか、検索に大きく依存しようとすることです。
私の経験では、階層に入れる時間が長くなり、オプションのセットが長くなるほど、実際に正しいカテゴリを選択するのに時間がかかることが少なくなります。最も具体的なカテゴリを選択するために数秒余分に作業するよりも、デフォルトのままにするか、最もあいまいなカテゴリを選択する方が簡単です。
それらを本当にシンプルに保ち、カテゴリが報告する内容を反映していることを確認してください。サーバーまたはワークステーションごとに障害を報告するだけの場合は、すべてのログエントリをナビゲートするのが面倒な大きな階層ツリーを追加することは意味がありません。
レポートにあまり煩わされていない場合は、事前定義されたカテゴリをまったく作成しないでください。ほぼ確実に、スキーマに適合しないものに出くわし、そのために誤って分類する必要があります。
クラス、カテゴリ、タイプ、およびアイテムの分類法を探しています。不足しているのはある種の構成データベース（ITEMリストに役立つ）であるため、行き詰まっています。もう1つの問題は、ヘルプデスクソフトウェアを使用して、どのサーバーで最もダウンタイムが発生したかではなく、特定の問題によって影響を受けるサービスを特定する必要があることです。サービスベースのモデルを選択すると、クラス、カテゴリ、タイプ、およびアイテムの決定が非常に簡単になります。グループ（クラス）、アプリケーション（カテゴリ）、サービス（タイプ）、実際に壊れているもの（アイテム）として考えることをお勧めします。また、時間とチケットの関係を使用して、環境全体の問題の影響を示すことができるためです。次に例を示します。
チームが自分の電子メール（CCTIはWindows、Exchange、電子メール、クライアントである可能性があります）にアクセスできないため、ユーザーが電話をかけます。Exchangeの担当者はExchangeを調べ、Exchangeが他のすべてのユーザーにとって問題なく実行されていることを報告し、ネットワークの問題を追跡します。ネットワークグループにインフラストラクチャを見てもらうために、彼のチケットを閉じて、新しいチケットを開く必要があります。交換チケットは、スイッチが故障したことが判明したため、新しいチケット（CCTI、ネットワーク、内部、接続、デスクトップ）に関連付けられている必要があるため、チケットはその解決策で閉じられます。これで、電子メールに対して可用性レポートを実行すると、停止が表示され、ネットワークの問題に関連していることがわかります。
私はあなたと同じようなジレンマを持っています。現在、このトラッカーを使用する必要のある3つのビジネスユニットがあり、選択マトリックスを使用して、誰にどのカテゴリの通知を行うかを決定しますが、誰がどのカテゴリに投稿することもできます。
ビジネス間を移動するスタッフがいるため、実際にはビジネス名にTier 1カテゴリを使用し、サポート領域にTier2を使用しています。例えば：
- アルファ
- O/Sの問題
- アプリケーション1
- A/V機器
- ブラボー
- O/Sの問題
- アプリケーション1
- A/V機器
- チャーリー
- O/Sの問題
- アプリケーション1
- A/V機器
このスキーマはまだかなり新しいので、（まだ）問題は発生していません。
私には2つのことが突き出ています。あなたの質問を読み直します。
- これはあなたにとって正しいトラッカーですか？必要な機能が不足しているようです。おそらく、この特定の仕事のための別のツールを見つける時が来ましたか？
- アイテムを分類するときの一般的なルールは、ツリー階層の上位にあるほど、アイテムの範囲が広くなります。方向は、最も広い定義から最も狭い定義までである必要があります。
サテライトオフィスはいくつかありますが、非常に小さく、基本的に1人のITスタッフで対応できます。本当の解決策はタグ付けではなく、サブスクライブです。本当に物事をそのまま処理できない場合は、複数の割り当てを行えることが重要な機能です。
別の例：Launchpadは「影響も」提供し、コメントを単一のスレッドにプールします。このようなものは、NYの技術者とサーバーの技術者の両方をサブスクライブし、発生する（または発生しない）相互作用を文書化できます。