MENU
×

MENU

ロジックエラーを打開するサービスレベルの考え方

引き続き、ITILについて解説します。
前回は、ITILのコアコンセプトであるサービスレベル管理において、ロジックエラーを内包しているケースが多く、顧客満足が向上しないわりに内部態勢は高負荷に疲弊していくという現象を誘発しているという論を提示しました。

今回は、そのサービスレベル管理におけるロジックエラーを打開するサービスレベルの考え方について解説します。

これについては、正直なところ、IT業界のリファレンスとして浸透しつつあるITILにおいて、サービスレベル管理に関する言葉の定義も一つの原因と考えています。
ITILの中では、サービスレベルに関して、SLA・OLA・UC※という大きく3つの言葉を定義しています。

※SLA:Service Level Agreement
※OLA:Operational Level Agreement
※UC :Under Opinion Contract

これらの言葉の定義に一貫性が欠けているのです。
例えば、SLA・OLAはともにAgreementとして同レベルのように捉えられますが、そうするとOperationとServiceと言われても両
者の区別が分からなくなり、結果、OLAという言葉は実質上有効性を持っていないケースが大半です。
あるいは、SLA・OLAは、あくまで合意であり、UCの契約という表現よりも一段緻密性や厳格性といったものが低いように見受けられます。
方や、UCはあくまで下請け業者との契約を指すものであり、本来的に顧客との合意形成であるSLAやOLAがUCの上位概念と考えられます。
このように、上位概念と下位概念が錯綜しているため、本来一連のロジックとして設計すべきサービスレベル管理が機能しておらず、バラバラの要素としてしか理解されていないのです。何か窺い知れない深い意図があるのかもしれませんが、いずれにしても、直感的にミスリードを誘発するような表現は適切とは言えないでしょう。

では、これらを踏まえてSLA・OLA・UCの考え方を整理します。
答えは簡単で、ITILの定義に囚われず上下関係をもって再整理すれば良いのです。
ITILはあくまでリファレンスですから、その定義に固執することに意味はありません。言葉遊びに振り回されてロジックエラーを起こすようでは本末転倒です。
では、SLA・OLA・UCのロジックを整理しましょう。

最上位=SLA=IT稼動の結果品質に関する合意/契約
第二位=OLA=SLAを担保する内部態勢に関する合意/契約

まず、SLAとOLAの関係を明確化します。
SLAとOLAはAgreementとして並列ではなく、SLAを上位概念の結果品質とし、OLAは、SLAを担保するために必要な業務の提供レベルとして従属します。
例えば、99.95%/月(=24時間×30日)のシステムアベイラビリティをSLAとして定義しているとします(時差なし)。
つまりこれは、単純計算で1.2H/日のシステム停止しか許容しないという合意形成となります。
よって、SLAに従属するOLAとしては、1.2H/日でのトラブル復旧を担保するオペレーションとして、例えば監視ツールによる5分インターバルの障害監視を行い、24時間態勢をとるという合意形成となります。
さらに例えば24時間態勢を自社スタッフでとることができない場合、外部業者とUCによって24時間態勢を担保するための合意形成をするということになります。
但し、UCとして一括りにしてしまうとSLA・OLAのロジックが見えづらくなってしまうので、UC-SLA・UC-OLAといった形でポジションを明確化します。
そして、ITサービスの業務プロセスはあくまでSLA・OLAを担保するために存在するというシンプルなものとします。
このようにしてコアプロセスと例外プロセスを明示的に切り分けることによって、顧客満足と業務負荷軽減のバランスが可能となります。
(この記事は2008年3月31日に初掲載されたものです。)