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

 

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

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

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

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

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

チケット管理システムを導入するメリット

社内の多くの業務を効率化することができるITチケット管理ですが、具体的なメリットは以下のようにまとめることができます。

すべてのチャネルからの問い合わせを一元管理できる

サービスデスクにはメールやチャット、電話などさまざまなチャネルから問い合わせがあります。形式の異なる問い合わせを人力で整理して、対応漏れが起こらないように管理するのは容易ではありません。

チケット管理システムでは、いずれのチャネルからの問い合わせも「チケット」として一か所に集めて管理します。

すべての問い合わせの対応状況を一覧で確認できるため、対応漏れを防止できるほか、一人のユーザーが複数のチャネルから問い合わせを行った場合でも、同一の問い合わせを特定し、対応の重複を防ぐことができます。

問い合わせの分類を容易にする

チケット管理システムでは、問い合わせチケットにカテゴリやタグを設定して、問い合わせを自動で分類します。

これによって、問い合わせの内容ごとにメールフォルダを分類するといった、面倒な作業がなくなります。

担当者への割り振りをスムーズに行える

チケット管理システムでは、カテゴリやタグごとに必要なスキルを設定することができます。また同時に、対応スタッフのスキルや役割を登録し、稼働状況を記録することもできます。

チケット管理システムはこの両者を照らし合わせて、適切な担当者に自動で作業を割り振ります。例えば、パスワードリセットのような簡単な問い合わせは新任の担当者に、重要なインシデントについては経験豊富な上位の担当者に振り分ける、といった設定が可能です。

ワークフローを設定できる

すべての問い合わせをチケットとして管理することで、類似の問い合わせへの対応方法がデータとして蓄積されていきます。

繰り返し寄せられる問い合わせには、蓄積されたデータをもとに担当者のワークフローを設定することができます。

ワークフローが設定されたチケットは、担当者に割り当てられた際に対応手順が明示されるようになり、スムーズな解決を手助けします。

問い合わせの優先度付けを行える

サービスデスクにはあらゆる問い合わせが届きますが、限られたサービスデスクのリソースでは、すべての問い合わせを即時に解決することは困難であるため、問い合わせの優先度付けが重要です。

チケット管理システムでは、緊急性や業務への影響の大きさなどをパラメーターとして、自動で問い合わせの優先度付けを行います。

たとえば、セキュリティに関するインシデントは、組織に与える影響が大きく緊急の対応を必要とするため、他の問い合わせよりも高い優先度が付けられます。

優先度の高い問い合わせは、対応できるスキルを持った担当者や部門に緊急の案件として割り当てられます。もし割り当てられた担当者が別のチケットに対応していた場合は、必要に応じて別の担当者に割り当て直されます。

ITチケットとITIL

ITIL(Information Technology Infrastructure Library)とは、ITサービスマネジメント(ITSM:IT Service Management)の成功事例をまとめた書籍群です。

ITSMの導入は多くの企業にとって重要な経営課題ですが、要求範囲が広大なため、具体的な取り組み方法や導入の優先度設定を、自社ですべて検討することは現実的ではありません。そこで、ITSM導入のガイドラインとして、ベストプラクティスを提供しているのがITILなのです。

ITILでは、ITチケットを中心に取り扱っている項目はありませんが、チケットシステムが管理する対象である、インシデントやサービス要求については、重点的に解説しています。

また、サービスオペレーションの項目には、ITチケット管理のベストプラクティスが含まれています。

チケットの種類

IT部門には様々な業務がありますが、その多くがITチケットとして扱われます。

それぞれを独立して扱うのではなく、チケットとしてすべてを一元管理する理由は、ほとんどの業務が、共通のデータを利用して、共通のライフサイクル/ワークフローに従い、そして多くの場合同じチームによって対応されるためです。

全てを同様にチケットとして扱うことで、タスク管理の効率を上げ、スタッフの生産性を向上させます。

また、発生した問題と対応を記録することで、サービスが抱える問題点や改善点を発見するための、データ分析やレポートの作成を効率的に行うこともできます。

イベントチケット

イベントチケットは、IT環境で発生する事柄を記録するものです。

イベントの例としては、リリース、停電、メンテナンス、変更の導入などがあり、イベントによって期間や規模は異なります。

アラートチケット

アラートチケットは、IT環境に問題が発生した可能性がある場合、もしくは、事前に定義した条件を外れた場合に生成されるものです。

ほとんどのアラートは、システムによる監視とエラーの発見によって自動で生成されます。

インシデントチケット

インシデントチケットは、ITサービスにおける計画外の中断や品質の低下、またはサービスに影響を及ぼす前の段階の障害を指します。

インシデントの例としては、停電、エラー、パフォーマンスの問題などがあります。インシデントチケットは、何らかのイベントに対応して開始と終了が定義されます。

リクエストチケット

サービスリクエストチケットとも呼ばれ、ITサポートチームが運用中のシステムやサービスに対して行う、アクセスの要求、パスワードのリセット、データの更新、サービスのプロビジョニングなどの日常的な活動です。何かに問題があることを示すものではなく、何かを行う必要があることを示すものです。

 

チケットの作成

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

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

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

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

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

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

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

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

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

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

チケットのソース

ITチケットには、主に3つのソースがあります。チケットは「活動や問題の記録」であるため、チケットのソースは「活動や問題の原因」ではないことに注意してください。

システムが生成したチケット

最近のITシステムの多くは、監視やエラー処理の機能を備えており、異常なイベントや状態が発生すると、自動的にITSMシステムにチケットが記録されるようになっています。チケットの一部はこうして、ITシステムが自動生成したものです。

ユーザーが生成したチケット

ITシステムやサービスのエンドユーザーが、セルフサービスポータルや電子メール、サイト内の「ヘルプ」機能を通じてサポートを要求して生成されたチケットです。ITチケットの最も一般的なソースです。

エージェントが生成したチケット

サポート活動が開始されたものの記録がまだ存在しない場合に、サービスデスクのエージェントが手動で生成するチケットです。ヘルプデスクへの電話、メンテナンス活動、監視アラートなどがあった場合に生成されます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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も対応のスピードに重点を置いています。

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

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

エスカレーション

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

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

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

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

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

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

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

other data other data

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

他のITSMプロセスとのワークフローの連携

チケット管理のベストプラクティスでは、チケット管理のプロセスを、組織内の他の関連するITSMプロセスと連携することを推奨しています。

ソリューション開発

チケットには、ITシステム・サービスのパフォーマンスや使い勝手を向上させるために、開発者が参考にすべき機能要求やユーザーからのフィードバックが含まれている場合が多くあります。

変更管理

変更依頼は、多くのITチケットの開始や解決に直接関係することが多いものです。変更管理とチケット管理が連携することで、計画された変更の有効性をより理解することができます。

ナレッジ管理

チケットへの対応は、エージェントが過去のチケットから学んだ経験や教訓を活用することでより効果的になります。チケット管理プロセスには、ナレッジベースの作成と参照の両方を組み込むべきです。

システムの監視

監視機能とシステムで生成されたチケットの連携は、プロアクティブサポート(ユーザーが影響に気付く前に問題を解決すること)の基礎となります。

問題管理

ITチケットは、IT環境における問題を特定、診断、解決するための重要なデータソースです。また、問題管理は、ITシステムの既知の問題データのソースでもあるため、チケット管理と問題管理の連携は両者にとってパフォーマンスを向上させる効果があります。

ITチケット管理のベストプラクティスには、チケットを処理すること自体ではなく、原因となったユーザーの問題を解決するためにこそ、人材、プロセス、データ、システムを最適化するべきだという共通するテーマがあります。チケット管理システムを導入する際にはそのことを忘れないでください。