引き続き、ＩＴＩＬについて解説します。
前回は、ＩＴＩＬのコアコンセプトであるサービスレベル管理において、ロジックエラーを内包しているケースが多く、顧客満足が向上しないわりに内部態勢は高負荷に疲弊していくという現象を誘発しているという論を提示しました。
今回は、そのサービスレベル管理におけるロジックエラーを打開するサービスレベルの考え方について解説します。
これについては、正直なところ、ＩＴ業界のリファレンスとして浸透しつつあるＩＴＩＬにおいて、サービスレベル管理に関する言葉の定義も一つの原因と考えています。
ＩＴＩＬの中では、サービスレベルに関して、ＳＬＡ・ＯＬＡ・ＵＣ※という大きく３つの言葉を定義しています。
※ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ
※ＯＬＡ：Ｏｐｅｒａｔｉｏｎａｌ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ
※ＵＣ ：Ｕｎｄｅｒ Ｏｐｉｎｉｏｎ Ｃｏｎｔｒａｃｔ
これらの言葉の定義に一貫性が欠けているのです。
例えば、ＳＬＡ・ＯＬＡはともにＡｇｒｅｅｍｅｎｔとして同レベルのように捉えられますが、そうするとＯｐｅｒａｔｉｏｎとＳｅｒｖｉｃｅと言われても両
者の区別が分からなくなり、結果、ＯＬＡという言葉は実質上有効性を持っていないケースが大半です。
あるいは、ＳＬＡ・ＯＬＡは、あくまで合意であり、ＵＣの契約という表現よりも一段緻密性や厳格性といったものが低いように見受けられます。
方や、ＵＣはあくまで下請け業者との契約を指すものであり、本来的に顧客との合意形成であるＳＬＡやＯＬＡがＵＣの上位概念と考えられます。
このように、上位概念と下位概念が錯綜しているため、本来一連のロジックとして設計すべきサービスレベル管理が機能しておらず、バラバラの要素としてしか理解されていないのです。何か窺い知れない深い意図があるのかもしれませんが、いずれにしても、直感的にミスリードを誘発するような表現は適切とは言えないでしょう。
では、これらを踏まえてＳＬＡ・ＯＬＡ・ＵＣの考え方を整理します。
答えは簡単で、ＩＴＩＬの定義に囚われず上下関係をもって再整理すれば良いのです。
ＩＴＩＬはあくまでリファレンスですから、その定義に固執することに意味はありません。言葉遊びに振り回されてロジックエラーを起こすようでは本末転倒です。
では、ＳＬＡ・ＯＬＡ・ＵＣのロジックを整理しましょう。
最上位＝ＳＬＡ＝ＩＴ稼動の結果品質に関する合意/契約
第二位＝ＯＬＡ＝ＳＬＡを担保する内部態勢に関する合意/契約
まず、ＳＬＡとＯＬＡの関係を明確化します。
ＳＬＡとＯＬＡはＡｇｒｅｅｍｅｎｔとして並列ではなく、ＳＬＡを上位概念の結果品質とし、ＯＬＡは、ＳＬＡを担保するために必要な業務の提供レベルとして従属します。
例えば、９９．９５％／月（＝２４時間×３０日）のシステムアベイラビリティをＳＬＡとして定義しているとします（時差なし）。
つまりこれは、単純計算で１．２Ｈ／日のシステム停止しか許容しないという合意形成となります。
よって、ＳＬＡに従属するＯＬＡとしては、１．２Ｈ／日でのトラブル復旧を担保するオペレーションとして、例えば監視ツールによる５分インターバルの障害監視を行い、２４時間態勢をとるという合意形成となります。
さらに例えば２４時間態勢を自社スタッフでとることができない場合、外部業者とＵＣによって２４時間態勢を担保するための合意形成をするということになります。
但し、ＵＣとして一括りにしてしまうとＳＬＡ・ＯＬＡのロジックが見えづらくなってしまうので、ＵＣ－ＳＬＡ・ＵＣ－ＯＬＡといった形でポジションを明確化します。
そして、ＩＴサービスの業務プロセスはあくまでＳＬＡ・ＯＬＡを担保するために存在するというシンプルなものとします。
このようにしてコアプロセスと例外プロセスを明示的に切り分けることによって、顧客満足と業務負荷軽減のバランスが可能となります。
（この記事は2008年3月31日に初掲載されたものです。）
