ポイント: ITサービス管理における効果的なサービスレベルアグリーメント（SLA）に関する6つのベストプラクティスは、各サービスのために特定のSLAを作成し、顧客の成果に整合させ、測定可能であることを強調しています。定期的なレビューと明確な例外の定義は、サービス品質を維持するために重要です。
- 各ITサービスのために別々のSLA
- 顧客の成果に合わせたSLA
- SLAを定期的に見直し、調整する
ITIL 4によれば、サービスレベルアグリーメント（SLA）は「サービスプロバイダーと顧客との間の文書化された合意で、必要なサービスと期待されるサービスレベルの両方を特定します。」簡単に言えば、SLAはITサービスプロバイダーと顧客がサービス契約時に期待することを定義します。ITILサービスライフサイクルでは、SLAは二つの主要な領域で定義され、修正されます：
- サービスデザイン
- 継続的サービス改善
これは、ITサービスのSLAは新しいサービスや更新されたサービスの仕様と共に作成されるべきであることを意味します。ITサービスが設計されたり変更されたりするたびに、そのSLAも見直され、修正されるべきです。それが公平で、強制可能で、現実的であることを確認してください。これを踏まえて、ITサービス管理（ITSM）環境でのITサービスSLAを作成し、実行するための6つのベストプラクティスを以下に示します。
1. 測定が必要な各ITサービスのために別々のSLAを作成する
SLAは、サービスプロバイダーが顧客に対して行う約束の集まりです。サービスカタログ全体のために単一のSLAを作成することは避けてください。たとえば、すべてのITサービスリクエストが5時間以内に満たされると定義するのではなく、追跡したい各ITサービスのために別々のSLAを作成してください。具体的であるよう努めてください。いくつかの例は以下の通りです：
- 承認された新規ユーザーリクエストフォームを受け取ってから1日以内に新規ユーザーが作成されます。
- ユーザーの退職は、友好的な退職の場合は最後の日の終わりに処理され、友好的でない退職の場合は即時に処理されます。
- 新しい電話は、リクエストから1週間以内に注文され、配達されます。
各ITサービスにはそれぞれのリードタイムと承認スケジュールがあり、それに応じて完了しなければなりません。
2. 組織のすべての部門をカバーするSLAを作成しない
多くの異なる場所や部門を持つ組織にサポートを提供している場合、複数の場所をカバーするSLAを作成する際には注意が必要です。異なる運営ユニットには異なるサポート要件がある場合があるため、傘SLAは各場所を十分にサポートできないかもしれません。たとえば、プリンタサポートを提供している場合、顧客は平日の午前8時から午後5時の間に4時間の応答時間を要求するかもしれません。これは、技術者が多くいる都市部では簡単に満たせるかもしれませんが、技術者が少なく、離れた場所に住んでいる田舎ではその4時間の応答を維持することが難しいかもしれません。このような状況では、地域ごとのサービスの詳細を定義するか、各地域のために別々のSLAが必要になるかもしれません。
3. SLAを顧客の望ましい成果と整合させる
SLAは、顧客の望ましい成果に対して作成されるべきです。サービスプロバイダーがSLAの指標（サービスの稼働時間など）を満たしている間に、顧客の本当の目標をサポートできていない「スイカ効果」に注意してください。
従来のSLAは、通信回線は99.1%の時間稼働している必要がありますのようなIT運用指標を使用します。これらのSLAは数字を管理しますが、顧客の望ましい成果の文脈を欠いています。代わりに、顧客の実際の望ましい成果を反映する真実の測定と指標を使用してください。たとえば、あなたのSLAは、通信回線の99.9%の稼働時間を保証するかもしれません。あなたのテストでは、その指標を満たしていることが示されていますが、.1%のダウンタイムは、顧客の最も忙しい時間帯に発生します。NCAAトーナメント中やAmazonプライムデーのように、通信トラフィックが急増する時です。その.1%の障害中にサービスが落ち、顧客は不満を抱きます。スイカのように、サービスプロバイダーは、外側で満たされている緑のSLAを見ている一方で、顧客は内側で失敗している赤のSLAを見ています。ユーザーは、回線が混雑しているときに接続を失っています。可能な限り、顧客のSLAに対する望ましい成果を発見し、その成果に書かれたSLAを作成してください。置き換えられた成果ベースの指標SLAは、冗長な通信サービスが午前6時から深夜までのユーザーアクセスを中断なく提供しますとなるかもしれません。成果ベースのSLAは、数字を管理するのではなく、顧客の望ましい成果を管理します。成果ベースのSLAは、ITサービスプロバイダーとして顧客のサービスを管理する方法にも影響します。この重要なベストプラクティスは、SLAを作成および修正する際に顧客と関わり、顧客の意見を聞くことに依存しています。彼らをプロセスの一部にさせて、彼らがあなたのサービスレベルを理解できるようにし、あなたが彼らのニーズに合わせてSLAを書くことができるようにします。
4. SLAを測定可能にする
サービスデスクは、SLAが達成されたかどうかを判断するために必要な指標を収集し、提示できなければなりません。SLAはSMARTゴール—具体的、測定可能、達成可能、関連性のある、タイムリーである必要があります。各個別のSLAは以下の特性を持たなければなりません：
- Specific. SLAは具体的で詳細であり、サービス提供の期待を定義する必要があります。
- Measurable. 約束されたSLAに対する実際のパフォーマンスを追跡する方法が必要です。多くのサービス管理プラットフォームには、SLAの約束と、そのアイテムに対して記録された実際の時間またはその他のサービス測定を比較するための機能が含まれています。基本的な管理ツールにSLA目標やサービスカタログアイテムを提供中に使用される測定が含まれていない場合、SLAパフォーマンスを蓄積し、証明することは難しいです。
- Achievable. SLAは現実的で、満たされる可能性があるものでなければなりません。非現実的な目標は、サービス提供チームのやる気を削ぐ可能性があります。
- Relevant. SLAは、提供されるITサービスに直接関連し、その目標に対するパフォーマンスを評価するために関連性がなければなりません。
- Timely. SLAには、サービスが提供される時間枠が含まれていなければなりません。
ITサービスプロバイダーは、SLAパフォーマンスに関するデータを収集し、またそのパフォーマンスを報告する能力を持たなければなりません。サービス管理ソフトウェアが両方のタスクをこなせることを確認してください。
5. SLAを定期的に見直し、調整する
ITIL継続的サービス改善のコアエリアの一部として、SLAはそのサービスに対する提案されたまたは約束された変更があるたびに見直し、更新されるべきです。サービス時間、可用性、稼働時間、完了、応答時間など、顧客の望ましい目標に影響を与える変更に対して調整してください。ITサービス改善の時期にSLAを見直し、調整しない企業は、サービスレベル目標をもはや満たさない可能性があります-その結果、顧客を失ったり、SLA非遵守による罰則を受けたりする可能性があります。
6. SLAが通常および異常な例外を考慮することを確認する
SLAが適用されない場所を定義することも、適用される場所を定義することと同じくらい重要です。SLAは、ITサービス処理を妨げたり、防いだりする通常および異常な状況を定義するべきです。いくつかのSLAの例外は以下の通りです：
- すべての注文は、日曜日の午前1時から午前4時のシステムメンテナンス中を除き、受領から1時間以内にリリースされます。
- 新しいコンピュータは、5営業日以内に構成され、配達されます。配達期間内に祝日がある場合は、追加の日数が必要です。
- 新しいユーザーは、管理がユーザーの追加を承認している場合、完了した新規ユーザーフォームの受領から1日以内にシステムに追加されます。新しいユーザーリクエストが受領されたが、管理が新しいユーザーを承認するのが遅れている場合、サービスレベルのミスとは見なされません。
- SLAターゲットは、サービスに影響を与える地域的または地方的な災害が発生した場合に、一時的に免除されます。これには、火災、洪水、地震、パンデミック、延長電気またはネットワークの中断などが含まれます。
追加リソース
サービスレベル管理についての詳細は、BMCサービス管理ブログを参照し、以下の記事をチェックしてください：
- サービスレベルアグリーメント（SLA）の例とテンプレート
- ITILサービスデザインプロセス
- ITIL継続的サービス改善
これらの投稿は私自身の意見であり、必ずしもBMCの立場、戦略、または意見を表しているわけではありません。