サービス リクエスト実現
Information Technology Infrastructure Library (ITIL) のサービス リクエストの範囲は広大です。タスクの範囲は、パスワードのリセットから、新入社員の研修にまで及びます。サービス リクエストには、カスタマーのコメント、苦情、または情報を求めるその他のリクエストが含まれます。
IT Service Desk テンプレートには、以下のようなリクエスト タイプが事前に組み込まれています。これらは、サービス デスク エージェントが一般的なサービス リクエストを処理する上で役立つように設定してあります。
サービス リクエスト フルフィルメント プロセス:
- カスタマーの期待の管理
- リクエスト解決の迅速化
- 承認プロセスの標準化
効果的なサービス リクエスト管理は、官僚主義と IT サービスを維持するコストを削減します。
このページでは、Jira Service Desk を使用してサービスリクエストを履行するためのベストプラクティスをいくつか紹介します。ITIL の推奨事項を最適な形でビジネスに生かす方法を習得する正式なトレーニングを探すこともできます。
サービス リクエスト フルフィルメント プロセス
サービス リクエストをキャプチャーし、解決するために必要な情報は様々です。しかし、これらのリクエストを遂行するためのプロセスは標準化できます。
IT Service Desk テンプレートは特定のリクエストをサービス リクエスト フルフィルメント ワークフローに関連付けます。このワークフローは、サービス リクエスト フルィルメント プロセスを補完するために設定されています。サービス デスクの出発点として使用してください。
サービス リクエスト フルフィルメント プロセス概略:
- カスタマーがサービス カタログまたはメールを利用してヘルプを要求します。
- サービス デスクは、定義済みの承認および認定プロセスに沿ってリクエストを評価します。必要に応じて、財務またはビジネスの承認を得るためにリクエストを送信します。
- サービス デスク エージェントはこのサービス リクエストの遂行に取り組むか、遂行可能な人にリクエストを転送します。
- リクエストを解決すると、サービス デスクはチケットをクローズします。エージェントはカスタマーが満足しているかどうかを確認するためにカスタマーの意見を聞きます。
Jira Service Desk の既定のサービスリクエスト ワークフロー
リクエストタイプを使用して、サービスリクエストと呼ばれる課題タイプにサービスリクエストを関連付けることができます。これにより、課題は推奨されるサービスリクエスト フルフィルメントワークフローに配置されます。
このワークフローは上記の基本プロセスに従っています。これをカスタマイズし、ビジネスのニーズに合わせて変更できます。
テンプレートには２つのタイプのサービスリクエストが含まれています。
- サービスリクエストには承認ステップはありません。事前承認済みのサービスリクエスト用にこれらを使用することをお勧めします。
- 承認付きサービスリクエストには承認ステップが含まれています。ビジネス上または財務上の承認のいずれかが必要なリクエストにこれらを使用することをお勧めします。
サービスリクエスト ワークフローのカスタマイズ
- In your service project, select Project settings (
) > Workflows. - 以下のいずれかの横にある編集アイコン (鉛筆) を選択します。
- Jira Service Desk のサービス リクエスト フルフィルメント ワークフローというタイトルのエントリ
- Jira Service Desk の承認付きサービス リクエスト フルフィルメント ワークフローというタイトルのエントリ
- ワークフロー エディターを使用して、ステップとトランジションを追加または編集します。
サービスリクエストの解決後にサービスリクエストを自動クローズ
IT Service Desk テンプレートには追加の SLA および自動化規則が含まれています。これらは連携して、エージェントによるサービスリクエストの解決後 3 営業日でサービスリクエストを自動的にクローズします。カスタマーから追加でフィードバックがある場合に備えてリクエストをクローズする前に待機するチームでは、これは有益です。
サービス リクエストの解決フィールドが設定されると、解決後のクローズまでの時間という名前の SLA が時間の記録を開始します。記録は、エージェントが解決フィールドをクリアするか、リクエストがクローズに移行した場合に停止します。
この SLA は表示、編集、または削除が可能です。
In your service project, select Project settings () > SLAs.
解決後 3 営業日以内に自動クローズという自動化ルールが含まれています。このルールは、上記の SLA 超過があると、サービス リクエストを解決済みからクローズに移行します。
このルールは無効化または調整できます。このルールを表示または編集するには、次の手順を実行します。
In your service project, select Project settings () > Automation.
ポータルにサービス リクエスト フォームを作成するためのヒント
- 最も一般的なリクエストから開始します。単純で、フルフィルメントが容易なものを選択します。これはカスタマーに即座に価値を提供します。これにより、サービス デスク チームはサービス カタログの今後のフェーズ構築に向けて学ぶことができます。
- カタログに追加する前に、サービス リクエストのすべての要件を文書化します。これらには、質問データ、承認プロセス、フルフィルメント手順、フルフィルメント チーム、プロセス オーナー、SLA、レポートなどが含まれます。これにより、IT チームのリクエスト タイプ管理は時と共に向上していきます。
- リクエストのフルフィルメントを開始するために必要なデータをキャプチャーします。しかし、カスタマーにあまりにも多くの質問をして負担をかけないようにしてください。
- 可能な場合は、承認プロセスを標準化するために利害関係者と協力します。たとえば、新しいモニターに関するすべてのリクエストを事前承認します。または、ソフトウェアの承認をカスタマーのマネージャーに割り当てます。
- カスタマーが自分でリクエストを解決できる可能性のあるナレッジ ベースの情報はすべて文書化します。これをリンクされた Confluence スペースに記録します。そうすれば、カスタマーはポータルで検索中に記事を表示できます。ナレッジ ベースの作成については、こちらをご覧ください。
- リクエストのフルフィルメントにおけるチームのパフォーマンスをレビューします。SLA、要件、および研修を調整して、カスタマー満足度を向上させます。
- レポートを作成し、サービス リクエスト オファリングのライフサイクル管理に役立てます。このようにすることで、不要になったフォーム、複雑すぎるフォーム、または不十分なフォームを発見できます。
サービス リクエストの既定フォーム フィールド
Jira Service Desk を使用することで、カスタマーから収集される情報のフィールドをカスタマイズできます。さらに、エージェントが使用する情報のフィールドもカスタマイズできます。Jira Service Desk は課題タイプ フィールドと画面を通じてこれを実行します。フィールドは、エージェントがリクエストのフルフィルメント、ベンダーとの話し合い、リクエストの分類を行う上で役立ちます。
既定では、エージェントのサービス リクエストのビューには次のフィールドが含まれます。
| フィールド名 | 説明 |
|---|---|
| 要約 | リクエストの短い説明。 |
| 報告者 | リクエストの送信者。 |
| コンポーネント | リクエストに関連する IT インフラストラクチャのセグメント。たとえば、"請求サービス" または "VPN サーバー" などです。これらはラベル付け、分類、およびレポートに使用されます。 |
| 添付ファイル | リクエストに追加されるファイルまたは画像。 |
| 説明 | リクエストの長く詳細な説明。 |
| リンクされた課題 | リクエストに影響を与える、またはリクエストの影響を受ける他のリクエストの一覧。ビジネスで他のアトラシアン製品を使用している場合、この一覧に、リンクされている開発課題が含まれる場合があります。 |
| 担当者 | リクエストのフルフィルメントを割り当てられたサービス デスク エージェント |
| Priority | サービス デスクにとってのリクエスト解決の重要度。通常、ビジネスのニーズと目標に関係します。優先度が影響力と緊急性によって計算されることもあります。 |
| ラベル | レコードの分類またはクエリに使用される追加カスタム ラベルのリスト。 |
| リクエスト参加者 | リクエスト解決に参加する追加のカスタマーまたはベンダーのリスト。 |
| 承認者 | サービス リクエストを承認するビジネスまたは財務担当者のリスト。 |
| 組織 | リクエストの解決に利害関係のあるカスタマーまたはベンダーのリスト。 |
ITIL が推奨する追加のフォーム フィールド
ITIL は、詳細なプロセスについては、いくつかフィールドを追加することを推奨しています。IT Service Desk テンプレートは、既定ではこれらを組み込んでいません。その理由は、Jira Service Desk を使用する IT チームは、多くの場合、これらのフィールドを使用しないからです。しかし、必要に応じて、これらのフィールドを組み込むか、カスタム フィールドを追加できます。Jira のフィールドについて詳細はこちらをご覧ください。
ITIL では、次のフィールドを含めることも推奨しています。
影響
- サービス リクエストの影響。通常は、サービス レベル アグリーメントに関連。
緊急性
- ビジネスがサービス リクエストの影響を受けるまでに利用可能な時間。
保留理由
- サービス リクエストが進行していない理由を示す短い説明またはコード。
製品分類
- リクエストが影響する IT 資産またはシステムのカテゴリ。
操作分類
- リクエストを遂行するために必要なアクションまたは機能の分類。
Learn more about IT service management (ITSM)
ITSM を成功させるために多くのヒントやコツを参照し、ワンランク上のサービス デスクを実現する方法を習得しましょう。「IT アンプラグドの ITSM リソース」を参照してください。