Close

ベロシティの高い ITSM の準備

SLA の設定、測定、レポート作成方法

SLA (サービス レベル アグリーメント) は、測定、報告、遵守が難しいことで倦厭されがちです。また、サービス デスクの多くでは、設定や変更も難しい場合があります。それでも、上位の目標に対してパフォーマンスを追跡することは重要であり、SLA は顧客満足度を向上させる絶好の機会を提供します。

サービス レベル アグリーメント (SLA) について

サービス プロバイダとしてのサービス レベル アグリーメントとは、(社内外を問わない) ユーザーとその顧客との間で交わされた分かりやすい言葉で認められている契約です。この契約では、提供するサービス、期待される応答性、どのようにパフォーマンスを測定するかについて定義します。

SLA は、アップタイムやサポート応答性など、サービスに関して契約上合意された条件を定義します。たとえば、顧客に 99.9% のサービス アップタイムや、24 時間以内のサポートからの回答を約束するなどです。SLA ではサービス期待度の形式化に加えて、要件に違反した際の救済条件も定められています。

SLA の重要性

SLA は、信頼を構築する上で重要な IT チームと顧客との間の基本契約です。顧客の期待を管理して、顧客が解決する責任がある課題をチームが把握できるようにします。SLA の準備を整えることで、サービス期待度に関する共通の理解へ到達できます。SLA を導入すると、次のようなさまざまな方法で IT チームにメリットがもたらされます。

  • 顧客との IT 関係の強化 - SLA はリスクに対する懸念を緩和して、当事者間の信頼を向上させます。違反が発生した場合に何が起こるかを定義することで、不確実性を減らします。
  • コミュニケーションの形式化 - IT 課題に関する関係者との会話は難航する場合があります。誰も 1 人の顧客から 1 日に 10 回も連絡が欲しいとは思いませんし、顧客のサービス パフォーマンスに対する暗黙の期待に裏で気に病んでもらいたくありません。SLA により関係者は、すでに合意された条件に基づいて順序立てられた会話を進められます。
  • 生産性と士気の向上 - SLA は、受け取ったリクエストの緊急性を定義します。IT チームに、受け取った課題のうちで最も重要な課題に専念してもらいます。

SLA と KPI の相違点

SLA はユーザーとその顧客の間の契約で、将来の関係の方向性を定義します。主要業績指標 (KPI) は、合意された基準に対するチームのパフォーマンスを測定するために選択される指標です。

たとえば IT サービス デスクは、通常はビジネス内のさまざまなサービスやデバイスのテクニカル サポートを提供することに合意して、アップタイム、最初の連絡での解決、サービス停止後の復旧までの時間などを保証します。KPI は、IT サービス デスクがこれらの保証を満たしているかどうかを追跡するために選択される特定の指標です。

SLA の課題

これは全くシンプルに聞こえますよね? 理論的にはそうです。しかし実際は、IT チームは次の 1 つ以上の大きな課題に直面することが多いです。

  • SLA の追跡は困難で、変更するにはさらなる困難が伴います。SLA に対するパフォーマンスを確認するには、多くの IT マネージャーが多数の生データを抽出してカスタム クエリを作成し、精巧な Excel の数式とレポートを構築する必要があります。さらに多くの場合、SLA はカスタム化するか多くのサービス デスクにハードコード化する必要があります。つまり SLA を変更するには、開発に数日もかかる尽力を求める可能性があります。
  • SLA がビジネスの優先事項と一致するとは限りません。SLA がビジネスと同じペースで変化したり進化したりすることは、皆無に等しいです。実際はそのまま継承されることがほとんどです。10 年前に誰かが SLA を設定したとして、それが現存するだけで喜ばれます。
  • レポート作成の柔軟性はほとんどありません。SLA の達成 (顧客からの返信にかかる時間など) に影響する固有の状況は多数ありますが、ほとんどの SLA レポートでは簡単には説明できません。SLA を満たしたか満たしていないかのどちらかです。その理由を示す、または継続的な改善に役立つものをレポートで強調する方法はありません。

SLA の設定とパフォーマンスの測定方法

以上のように、SLA が少し恣意的に感じられるか、企業のより大きなビジネス目標を直接サポートするものを測定しているとは限りません。適切なものを測定してビジネスの他の部分が抱えるユーザーの期待に応えるために、定期的に SLA を確認することをお勧めします。次のプロセスに従ってください。

  1. ベースラインを設定します。まず、現在の SLAとその SLA に対してどのようなパフォーマンスを発揮しているかを見ていきます。提供するものと、会社と顧客のビジネス目標にどのようにそれが対応しているかを評価します。
  2. 順調かどうかを聞いてみましょう。顧客と直接話し合って、建設的なフィードバックを集めます。何を上手くやっているのですか? もっと改善できることはありますか? 適切なサービスを提供していますか?
  3. 上記のステップの結果に基づいて、新しい SLA の下書きを作成します。不要になったサービスを取り除いて顧客の満足度を高め、ビジネスと IT の両方に価値をもたらすサービスを追加します。
  4. 経営陣からのサポートを受けましょう。SLA を成功させるには、IT リーダー、顧客組織のリーダーの協力も欠かせません。まず、自分の経営陣の同意を得て、顧客の経営陣との交渉をサポートしてもらいます。

上記のプロセスに従っていれば、SLA は相当に洗練されてくるはずです。

SLA のベスト プラクティス

現在のビジネス ニーズとカスタマー ニーズに対して最善の SLA をまとめたら、それを実行します。ここでは、SLA をまったく新しいレベルの使いやすさと効果に引き上げるためのヒントを紹介します。

顧客が返信するのを待っている間、解決までの時間の追跡を停止する SLA を作成する

IT 部門は、可能な限り最高のサービスを提供するために、独自の応答時間を効果的に測定できなければなりません。それでも、応答が遅い顧客やサード パーティによるエスカレーションにより、応答時間が実際よりも大幅に悪化するため、SLA の測定はすぐに複雑になります。測定およびレポート システムがこれらのような例外に対応できるようにすると、サービス デスク チームは実際のパフォーマンスに基づいて追跡されます。

エージェント エクスペリエンスを記録する

シンプルで明確な命名規則を使用してください。エージェントは、SLA の名前を読み取って、測定対象をすぐに理解する必要があります。目標を作り過ぎないように自重することも重要です。エージェントが目標を明確に理解できる必要があります。特殊な状況が多すぎるのもよくありません。目標を作れば作るほど、目標ごとの変動要素が増えるため、理解して遵守することが難しくなります。

大規模で複雑な SLA を分割する

複雑な SLA を作成するのではなく、一連の小さな SLA を使用して、全部ではなく個々のワークフローを測定してレポートできるようにします。こうすることで、SLA を更新して最新の状態に保つことも容易になります。

チケットの優先度レベルに基づいて異なるパフォーマンス目標を設定する

普段、サービス デスク チームはプリンターの障害を優先順位が最も高いチケットと見なしません。しかし CEO のプリンターだとしたら、別の問題になります。実際には、IT チームは影響を受けるのはビジネスのどの部分か、誰がチケットをオープンしたのか、さらに複雑な条件が絡み合ったもの (たとえば四半期末に販売予約システムに障害が発生した場合) など、実に多様な方法でチケットに優先順位を付けています。

サービス デスク ソフトウェアには柔軟性が必要なため、定義したパラメーターの組み合わせに基づいて、SLA パフォーマンスの目標を作成できます。チームの優先順位をビジネス ニーズの変化と完全に一致させるためには、それらを簡単に変更したり編集したりできることが重要です。

一部の SLA を年中無休で稼働させて、他の SLA を通常の営業時間に制限する

サービスデスクチームが月曜から金曜まで、通常の就業時間に働いているとしたら、どのサービスでも本当の 24 時間年中無休のサポートを提供することはできません。オンコールサービスデスクチームやカスタマーが料金を支払う優先サポートがあるとはいえ、サービスによっては、昼夜を問わない平日対応や即時対応を保証することが少なくありません。

土曜日と日曜日は中断するようにサービス デスクを設定しましょう。会社の休日など、カスタマイズされた規則を作成する場合はさらに複雑になります。また、異なる場所に拠点を置くチームをサポートするためにカレンダーの作成を検討します。

ビジネス目標に合わせた SLA を簡単に設定できるサービス デスク ソフトウェアをお探しの場合は、Jira Service Management を無料でお試しください。