ITチケット管理のベストプラクティス

ITチケット管理システムとは？どうして重要なのか

 

ITチケット管理システムとは、ITサポートチームが行った、あるいは行うべきタスクを「チケット」として記録し管理する仕組みです。

チケットは、ITサポートチームの社内での役割によって「サービスリクエスト」「トラブルチケット」「サポートケース」などと呼ばれることもあります。

一般的にはITSMS（ITサービスマネジメントシステム）の機能として搭載されており、ツールによっては、チケットに、カテゴリ・優先度・投稿者の属性・投稿チャネル・対応担当者などの設定、解決までにかかった時間や対応手順を記録できるものもあります。

こうした機能を、ヘルプデスクはユーザーとのやりとりの記録、運用チームは対処が必要な技術的な問題の追跡、IT部門の管理者はチームの作業量の把握やリソースの確保、サービスの改善計画立案など様々なシーンで利用しています。

ITチケット管理のベストプラクティスを活用し、チケットを効果的に管理することは、多くの業務の効率化、IT部門のコスト管理、ユーザーへのより良いシステムとサービスの提供を実現し、IT投資から最大限の利益を得るための重要な要素なのです。

 

チケットの作成

チケットの作成は、ITサービスマネジメントの中でも重要なステップです。

いつチケットを作成するか（またはしないか）、どのような情報を収集するか、どのようにチケットを作成するか、どのような初期応答をするか、といった選択のすべてが、IT部門の提供するサポートのスピード、品質、認知度に影響を及ぼすためです。

チケットを作成するかどうか

チケットというものは、活動や問題を記録するものでしかありません。

ある問題が発生した際に、チケットが作成されなかったとしても、問題を解決するために必要なタスクを誰かが実行しなければならないということに変わりはありません。

では、チケットを作成して記録するべき問題とそうでないものの違いは、どこにあるのでしょうか。

一般的なITチケット管理のベストプラクティスでは、以下の条件のいずれかが満たされる場合、チケットを作成することとされています。

• IT部門の誰かがタスクを実行する必要がある
• ユーザーの生産性に影響を与えるような問題が存在する
• 分析及び意思決定のための記録が必要である

しかし、これらの条件を満たしているにも関わらず、チケットを作成しないという選択をする企業がよく見られるケースが2つあります。

それは「ユーザーが自己解決した問題」と「手動で介入せずに（サービスの自動再起動などによって）解決されたシステムのアラートやイベント」です。

これらのケースのように、潜在的にユーザーに影響を与える可能性がある問題も、チケットとして記録する必要があるのです。

チケット作成時のデータの収集

ITチケットの作成時に収集し記録するデータは、サポートプロセスの効率化にとって非常に重要です。

根本的な問題を正確に表現し、それを分類し、適切な部門に振り分けるためには十分なデータを収集する必要があります。しかし、必要のないデータを収集して時間とリソースの無駄遣いをするのも望ましくありません

ところが、多くの企業では、どのようなデータが必要なのかがわからないため、過剰にデータを収集したり、後からデータを収集し直したり、すでに持っているデータ（ユーザーの連絡先、資産、位置情報など）を収集したりしてしまっています。

ITチケット管理のベストプラクティスによると、チケット作成のためのデータ収集では、既存のデータを活用するためのデータを取得することが最善であるとされています。

たとえば、ユーザーIDや電子メールアドレスを収集すれば、それを使って登録済みの連絡先や位置情報を検索できます。また、資産タグやデバイスの識別子を取得すれば、関連する資産やバージョン情報を調べることができます。そのほか、影響を受けたシステムやサービスの名前を取得すれば、監視データや変更履歴から原因を究明できます。

このようなアプローチを効果的に実施するには、チケット管理システムが、変更管理、IT資産管理、監視ツール、ユーザーアカウント・データベースなど、他のITSM機能とうまく統合されていることが必要です。

また、「ユーザーが生成したチケット」と「エージェントが生成したチケット」については、収集すべき追加データは「問題の影響範囲」「問題の再現手順」の2つであるとしています。これらの情報は、チケットの重要性を評価し優先順位を決めるために重要なので、チケット作成時に収集する必要があるのです。

チケットの依頼者への初期対応

ITチケット管理のベストプラクティスによると、チケットが作成されたこと、チケット番号、予想される応答時間、ユーザーが対応状況を確認できるリンクの情報を記載したメールは、チケットを受信したらすぐにユーザーに送信されるべきとされています。

これは、チケットの依頼者であるユーザーは、サービスデスクがすぐに対応することを期待しているためです。そして同時に、チケットの受信確認メールの送信をしないことによる、重複対応の発生を防ぐためでもあります。

チケットの構造に関するベストプラクティス

ITチケットは、ヘッダーと本文という構造で構成されるのが一般的です。

ヘッダーに含まれるデータは、チケット自体を管理するために使用されるものです。

具体的には、依頼者の情報、問題の簡単な説明、影響を受けるシステムの分類データ、SLAの計算に使用されるタイムスタンプなどが記録されます。

対照的に、本文に含まれるデータは、チケットの解決と分析に使用されます。

本文のデータには通常、再現手順、ユーザーとのやり取り、トラブルシューティングノート、チケットを解決するためにとったアクションなどが記録されます。

このようにそれぞれのデータが、違った役割に使われるため、ヘッダーと本文は区別できる構造にしておく必要があります。

専用データフィールドと自由に入力できるメモ形式

チケット管理システムを導入する際、専用フィールドに収集するデータと、自由に入力できるテキスト（メモ）フィールドに収集するデータを決める必要があります。

専用フィールドに入力されたデータは、分析、レポート、ワークフローの自動化に使用するのが簡単ですが、メモフィールドよりも入力にかなりの時間がかかります。

ITチケット管理のベストプラクティスにおいて、専用フィールドは、頻繁に更新されないヘッダーデータやシステムが生成するタイムスタンプのようなデータの入力に適しているとしています。ヘッダーデータは、チケットの優先順位付け、エスカレーションルール、レポート作成などに使用されるものです。専用のデータフィールドを設けることで、書式が統一され、これらの作業が容易に行えるようになるからです。

一方、チケットの本文には、診断データやユーザーとのやり取り、トラブルシューティングメモなどをコピー＆ペーストする機会が多いので、自由に入力できるメモ形式が最適とされています。

エージェントとユーザーに表示する内容

ITチケットは、閲覧者によって表示内容を変更する必要があります。

ITチケットには、詳細な技術情報、問題やセキュリティ上の欠陥のような機密性の高いデータが含まれることがあります。

こうしたデータをユーザー（依頼者）に表示することは、情報漏洩のリスクを高める行為です。また、問題解決のために必要以上の情報を提示することで、依頼者を混乱させることにもなります。

依頼者が見るチケットは、表示する情報を取捨選択したうえで、必要な情報が見やすいように編集されたものであるべきなのです。

そのため、ITチケット管理のベストプラクティスでは、エージェントのメモやリクエスト担当者とのコミュニケーションは、チケット本文とは別のフィールドで管理することを推奨しています。

チケットの分類

チケットの分類は、ITチケット管理の重要なプロセスです。

分類データは、SLAの設定、適切なサポートチームへのエスカレーション、データ分析、レポート作成のためのチケットのグループ化に使用されます。

チケットに含まれるべき分類データには、次の4つの重要な要素があります。

• 種類 - イベント、アラート、インシデント、リクエスト、質問など
• ソース - システム、ユーザー、エージェントの誰が生成したものか
• 優先度 - チケットが関連するシステム、ビジネスプロセス、タスクに割り当てられた優先度
• 重要度 - 時間的制約、ビジネスへの影響の度合い、問題の緊急性に関する評価

チケットは正確かつ一貫した基準で分類されることで、会社にとって最も重要な問題から、サポートチームに適切に対応されるようにすることができるのです。

チケットのルーティング

多くの場合ITSMSは、サポートチーム間のチケットの受け渡しを円滑にするために重要な役割を担っています。

しかし、最終的にチケットのルーティングは、エージェントと彼らがチケットに入力したデータによって制御されるものですので、チケットルーティングの仕組みに関するエージェント教育なくして、誤ルーティングを避け、効率的なチケットの受け渡しを実現することはできません。

ITチケット管理のベストプラクティスにおいて、以下の3つのルーティングシナリオはサポート部門のエージェントが知っておくべきとされています。

これら3つのルーティングシナリオがどのように機能するか、ルーティングルールをどのように開始し制御するか、チケットの所有権はどうなるかを確実に理解することで、より効果的にチケットを移行し、ユーザーが問題を迅速に解決できるよう支援することができるようになります。

社内サポートチームへのルーティング

チケットルーティングのほとんどが、社内サポートチームへのルーティングで、スキルや経験に基づいて専門の人材にタスクを割り振ります。

たとえば、アカウントのアクセス権に関連するチケットをアクセス管理チームにルーティングする、複雑なソフトウェアの問題をソースコードにアクセスできる経験豊富なスタッフにルーティングするといった形です。

社内サポートチームへのルーティングが行われると、元のエージェントはチケットの所有権を手放すため「再割り当て」とも言われます。

外部サポートパートナーへのルーティング

企業によっては、サードパーティのサポートベンダーや部品サプライヤーを活用してチケットの解決を行っています。

これらの外部パートナーは通常、サービスデスクと同じチケットシステムを使用していないため、パートナーにルーティングするには、パートナーのシステムでチケットを作成し、内部チケット内でそれを参照するという手段がよくとられます。

外部パートナーへルーティングを行った場合でも、社内の元のエージェントはチケットの所有権を保持し続け、外部パートナーが問題を解決する際に、ユーザーとのやり取りを仲介するというような業務を担当することがあります。

フォローザサンサポート（24時間対応）

多くのグローバル企業では、ITサポートスタッフが24時間体制で問題解決に当たっています。この体制を実現するためには、異なる地域に複数のサポートセンターを設置し、それぞれが連携する必要があります。ある拠点での勤務時間が終了しても、チケットへの対応を継続するために、別のサポートセンターにチケットをルーティングするのです。

このルーティングシナリオは、社内のサポートチームへのルーティングと同じですが、進行中の作業が受け渡される点に違いがあります。

チケットキューの管理

チケットが作成され、新しいサポートチームに割り当てられるときは、個人に直接割り当てられるのではなく、キューに入れられます。キューに入れることで、マネージャーやサポートチームのリーダーは、チームが行う作業に優先順位を付け、最も重要な問題が最初に対処されるようにすることができます。

多くの組織では、先入れ先出しでキュー管理を行いますがITチケット管理のベストプラクティスでは、以下の7つの要素を組み合わせて、キュー内のチケットに優先順位をつけることを推奨しています。

• チケットがキューに存在する期間
• 影響を受けるシステムまたはサービスの優先度
• 問題解決に必要なスキル
• 対象分野（専門的な知識またはアクセス要件）
• 問題の難易度
• 影響を受けるビジネスの地理的な条件（ユーザーの勤務時間や利用可能な時間帯を含む）
• 言語的条件

自動化ルールを設定することで、キュー内のチケットの優先順位付けを効率化出来ますが、これら7つの要因の主観的評価と利用可能なリソースとの比較が必要となることもあります。

また、SLAの遵守、容量の最適化、サポートコストなど、その他の考慮事項が優先順位付けの決定に関与する場合もあります。

チケット管理とSLA

SLA （Service Level Agreement）は、サポートチームのパフォーマンスをあらかじめ定義された基準に照らして評価するための指標となるものです。さらに、サポートチームや外部パートナーのパフォーマンスをコントロールするためにも役立ちます。

一般的にITチケットは、以下の2つのSLAで評価されます。

• 応答時間SLA - チケットが作成され、キューに割り当てられた後、担当者が受理し、対応が開始されるまでの経過時間
• 解決時間SLA - チケットが作成されてから、問題が完全に解決されるまでの総経過時間

どちらのSLAも対応のスピードに重点を置いています。

ITチケット管理のベストプラクティスでは、対応速度だけでなくサポートの品質と顧客満足度に関するSLAも設定し、エージェントがチケットを処理することに集中するのではなく、ユーザーに影響を与える根本的な問題の解決に集中するようにすることが推奨されています。

また、SLAの指標に加えて、以下の指標を追跡して、サポート業務の全体的なパフォーマンスを評価し、改善すべき領域を見つけ出すことを推奨しています。

• 再発率 - サポートの質を評価する尺度
• バックログ数 - 対応力とリソース容量の両方の問題の指標
• 取り組み時間 -チケットの難易度を簡略化した指標
• 受け渡し数 - ワークフローとルーティングルールの有効性
• ユーザー満足度 - コミュニケーションの有効性を測る指標
• 初回コール解決数 - エージェントのスキルとチケット作成時のデータ収集の指標

エスカレーション

ITチケットは複雑な場合があり、時には、エスカレーションが必要な場合があります。

エスカレーションはチーム内の他の誰かに助けを求める、あるいは、その問題に対処する資格がある別のチームにチケットを転送することによって行われます。

ITチケットのエスカレーションが起こる主なケースは3つあります。

• ユーザーがエスカレーションを要求する
• エージェントが、問題を解決するためのスキル、アクセス、知識が不足していることを確認する
• SLA目標未達(自動エスカレーション)

チケットのエスカレーションは、ルーティングと同じように行われます。エージェントは、チケットの現在のステータスを要約し、観察、仮定、欠落している情報、および実施した診断および修正アクションを記録する必要があります。この情報は、チケットを受け取った担当者が状況を迅速に評価し、サポートを提供し続けるために重要です。

チケット管理のベストプラクティスでは、エージェントが早期に必要性を認識し、解決できないとわかっているチケットに時間を浪費することを避けるために、エスカレーションを肯定的な行動として扱うべきであるとしています。

ITチケットと他のデータを連携させる

ITチケットは、ITサポート業務の中心的存在ですが、他のITSMやパートナーのデータと連携することで、その価値はさらに高まります。最低限、ITチケットを以下の関連データと関連付けることができるようにする必要があります。

効果的なデータ統合により、サポート担当者はこれらのデータにアクセスすることができ、チケットに再入力する必要がなくなります。これにより、時間と労力が節約されるだけでなく、ユーザーの問題解決に役立つ情報がより多く提供されることになります。