2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )ITIL® とは何か〜サービスマネジメントの重要な点を学ぼう〜
この記事は過去のブログに連載した記事を再編集したものです。

「ITIL® とは何か 〜サービスマネジメントの重要な点を学ぼう〜」 として、数回の連載でサービスマネジメントの最も重要な基盤となる知識を解説したいと思います。
まず第一回目は、 ITIL® の概要と特徴を解説します。 今回は 「ITIL® とは何か 〜サービスマネジメントの重要な点を学ぼう〜」 として、 サービスマネジメントの最も重要な基盤となる知識を解説したいと思います。

ITIL® とは何か？
ITIL® は IT サービスマネジメントを体系化したもので、1980 年代に英国政府で誕生しました。
現在はこれらの体系が 5 冊の書籍にまとめられています。
ITIL® とは何かについては、 これらの書籍の一つである 「サービスストラテジ」 の序章に以下のような記述があります。
ITIL® は IT サービスマネジメントのベストプラクティス書籍である。 ・ ・ ・ ITIL は世界中の組織に利用されており、 サービスを提供するあらゆる組織にベストプラクティスの手引きを提供する。
ベストプラクティスとは、 標準規格のように決められた通りに導入しなければならないというものではありません。 ITIL® は良質なサービスをいかに効果的かつ効率的に提供するのかを示した管理のガイダンス （手引き） であり、 組織の課題に合わせて適用することを目的としています。
なお、 ITIL® についての以下の二つの説明は誤りと言っていいでしょう。
「ITIL® はシステム運用の標準フレームワークである」
後述しますが、 ITIL® はライフサイクル全体を示しており、 運用段階だけを示したものであ2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )りません。
「ITIL® はシステム管理の作業手順を標準化したものである」
これは前述しましたが、 ITIL® はサービスの管理方法を示したものであって、 システム管理の作業手順ではありません。
サービスの管理方法とは、 品質、 リスク、 価値についてどのような戦略や指針を策定し、どのような管理プロセスで実行するのかということです。 もちろん、 現場では最終的には作業手順に落とし込む必要はありますが、 個々の作業手順は人員や技術などに依存するので、 作業手順の標準化は難しいでしょう （作業手順を標準化するには、 導入する IT インフラ製品を全て標準化するなどの戦略が必要であり、 結局は管理の問題になります）。
上記の説明は厳密には間違っているとは言えないのですが、 ITIL® の本質から遠ざけるような説明になっているので、 あえて誤りとしています。

ITIL® の特徴
ITIL® は他の IT マネジメントのフレームワークと何が違うのでしょうか？
ITIL® の特徴としては、 以下の 2 点が挙げられます。
1.IT＝サービスとして管理することを明確に示している。 したがって、 サービスの文脈を基盤として描かれている
2. サービスの 「ゆりかごから墓場まで」、 つまりサービスのライフサイクル全部を範囲としている
特徴の一つ目については、 IT は 「ものづくり」 の要素もありつつも、 その本質はサービスであるというところがポイントです。 これは、 実は多くの IT パーソンがなんとなく感じている点なのではないかと思いますが、 ITIL® はサービスとは何かと言った定義も含めてこの 「なんとなく感じているもの」 を明確化しています。 「ものづくり」 とサービスマネジメントの関係については非常に興味深いのですが、 これは別の機会に掘り下げてみたいと思います。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )特徴の二つ目のサービス ・ ライフサイクルについてですが、 ライフサイクル全体の管理を体系化したものは他に無いと思います。 システム開発の方法論 （メソドロジー） やプロジェク
ト管理については著名なフレームワークがありますが、 運用段階まで通した管理体系はあまり見られません。
ITIL® は運用段階やサービス改善まで含んだ管理体系を構築しましたが、 それゆえ、 ITIL®
はそのカバー範囲が広大になるという特徴も合わせもつようになりました。

ITIL® の本質
さて、 ITIL® がサービスマネジメントのベストプラクティスであることはわかりました。 ITIL®
では何を管理しようとしているのかついての最も本質的なコンセプトは、 以下の 2 点に集約されます。
サービス価値管理 (value managemnt)
サービス品質管理 (quality management)
この 2 点は昨今の 「ビジネスのサービス化」、 あるいは 「ものづくりからことづくりへ」 といった時代の潮流を考える上でも重要な概念となっています。
また、 サービスを提供するために必要な 「能力」 と 「リソース」 をどう管理するかという側面も考慮しなければなりません。
これらのトピックについては、 今後の連載で詳しく掘り下げていきたいと思います。

第二回目は、 サービスの価値について解説します。
前回の記事では、 IT は 「ものづくり」 の要素もありつつも、 その本質はサービスであるという点に触れました。 今回は、 モノとサービスの関係を掘り下げてみたいと思います。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )サービスとは何か？
サービスは 「顧客に特定のコストやリスクのオーナーシップを負わせない」 で提供されなければなりません。 例えば、 飲食店ではサービス提供のために食器類や厨房設備などが必要ですが、 これらの調達やメンテナンスは飲食店の責任です。 また、 食材の仕入れや衛生面の管理も飲食店の責任です。 顧客はこれらの設備を所有しませんし、 提供される料理に対する責任も負いません。 顧客が得るのは総体としての価値であって、 モノの提供を求めるのではありません。
さらに ITIL® では、 「サービスとは、 顧客に価値を提供する手段である」 と定義されています。
モノ （製品） にも色々な機能が付いており、 これがモノの価値となります。 しかし、 多機能化した製品についているたくさんの不要な機能は、 ある顧客にとっては価値がないのです。
顧客はいらない機能にまでお金を払いたくありません。
このように、 モノを提供するのではなく、 「ある顧客にとっての価値の部分だけを届けましょう」というのがサービスの本質です。

サービスの価値サービスの 「価値」 は最終的には顧客が決めます。 そして、 何が価値なのか？は顧客により異なります。
また、 サービスの価値は顧客が口にした言葉だけでは十分に定義できないことがあります。 なぜなら、 顧客自身も本当は何が必要なのかを理解していないケースが多々あるからです。
したがって、 サービスプロバイダは顧客の声を聞くだけの 「ヒアリング」 だけでなく、 顧客が本当にやりたいことや困っていることを分析する能力が必要です。
「我々のサービスの価値とは何か？」 は、 サービスプロバイダにとってもっとも基本的かつ根本的な質問です。 そして、 どのようなサービスやモノの組み合わせで顧客に価値を提供するかということを管理しなければなりません。 サービスプロバイダは、 様々な種類のサービスとモノを組み合わせてどのようなパッケージングにするのかをデザインする必要があります。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )サービスパッケージ
様々な種類のサービスとモノを組み合わせたものを、 サービスパッケージと呼びます。
モノ中心の世界では、 サービスはモノ （製品） の購入後のメンテナンスなどの 「付加的なサービス」 だという考えがありますが、 このような考え方は改める必要があるでしょう。 これからはサービスとモノを一体化したパッケージにして顧客に価値を提供するという、 サービス中心の考え方が重要です。
サービス中心の考え方に転換する理由としては、 以下が挙げられます。
ニーズの変容。
既存のモノ（製品）をさらに高性能化、あるいは多機能化していくという直線的な進化では、かえってニーズから遠ざかっていく可能性もあります。 そもそもモノを所有すること自体が顧客ニーズとしてどれほどのものであるかを検討しなければなりません。
技術革新。
特にインターネットを中心とした技術革新により、 情報の流れのスピードおよびコストが下がり、 モノが簡単につながるようになりました。 これにより、 単体のモノだけで止まっていた価値提供が途切れなくなり、 価値が 「モノの壁」 を超えて連鎖していくサービス化が進んでいます。
差別化。
現実問題として、 モノ単体の品質は多くの顧客にとって似たり寄ったりになっています。 競合他社に顧客を奪われないためには、 モノを使い始めた後で高い満足度を獲得しないといけません。 競争の中心は有形のモノから無形の価値 （つまりサービス） に移ってきています。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )自動車を例にすると、 新しいカーシェアリング ・ サービスは、 インターネット経由で自動車の予約やキャンセルが簡単にでき （利用 1 分前までキャンセル可能です！）、 施錠の管理なども人手を介さずに管理されています。 15 分単位で 24 時間利用でき、給油義務もありません。
通勤に車を使うなどして毎日車に乗らない人は、 ローンを組んで自動車を購入せずに、 カーシェアリング ・ サービスを活用することは合理的な選択肢になっています。
これは、 社会にとって自動車が不要になったのではなく、 個人で自動車を所有する価値が相対的に下がっているのです。
結局のところ、 人はニーズを満たせればよく、 そのためにモノを所有する必要性が少なくなります。 サービスを活用してニーズを満たしてしまうことができるようになるからです。
このように、 サービス中心の考えの根幹は、 「顧客ニーズの充足」 をどのように実現するのかという問題に取り組むことです。 もちろん、 よいサービスを実現するためにモノづくりの高い技術力も重要ですが、 技術が顧客ニーズとどのように関連するのかを管理することが重要です。

「ITIL® とは何か 〜サービスマネジメントの重要な点を学ぼう〜」 として、数回の連載でサービスマネジメントの最も重要な基盤となる知識を解説したいと思います。

第三回目は、 サービス戦略とサービス ・ ポートフォリオについて解説します。
前回の記事では、 サービスの定義と、 サービスの価値とは何かということを解説しました。
今回は、 サービス戦略とサービス ・ ポートフォリオについて、 その関係性も含めて解説します。

やらないことを決める
サービスの価値を考えるときにもう一つ重要なことがあります。 それは 「あらゆる顧客のニー2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )ズを完全に満たすことは極めて難しい」 という点です。 したがって、サービスプロバイダは 「やらないこと」 を決めることが戦略上重要になります。
「やることとやらないこと」 はサービスプロバイダの基本方針として明示されます。 そしてそれらが、 サービスの基本コンセプトとして重要な差別化要因となることがあります。
例えば、 スターバックスコーヒーは全店禁煙ですが、 当初は画期的だが長続きしないと見る向きもありました。 ところが、 実際には 「コーヒーの香りを楽しんでほしいので禁煙にする」というのはスターバックスのサービスコンセプトとして地位を確立しました。 これは見方を変えると 「喫煙者向けサービスはやらない」 という差別化戦略です。
このように、 やらないことを決めるというのは戦略的に重要な意味を持つことになります。
「あれもやろう、 これもやろう」 といった詰め込み型サービスは 「ほかと何が違うの？」 という質問に答えられないような、 特徴が無く差別化できないサービスになってしまうという欠点もあります。 「うちは全部できます！」 と言えれば良いのですが、 すべてにおいて競合に対して秀でることができるかは現実的に考えるべきです。
また、 顧客のリクエストにすべて答えるという 「リアクション型サービス」 では、 独自の価値提案ができなくなります。 さらに、 カスタマイズ要望に応えていくうちにサービスプロバイダ内部のリソースと能力が維持できなくなるというリスクも付きまといます。 オーダーメイド服の仕立て屋さんのようにカスタマイズ料金を請求できればそのような戦略も良いですが、 それが現実的かどうかもよく考えるべきです。
以上のように、サービス戦略では 「我々は何をやるべきなのか？」 を指し示すだけでなく、「何をやらないのか？」 も明確にしたほうが良いでしょう。

サービス ・ ポートフォリオ
サービスの価値は単なるサービスの企画段階のアイデアではありません。 サービスの価値は、 開発段階から運用段階を通して継続的に管理される必要があります。 この 「価値の管理」の中心となるのがサービス ・ ポートフォリオ管理です。
サービス ・ ポートフォリオ管理には、 以下の目的があります。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )・ サービスが明確に定義される
・ 適切なサービスの組み合わせを持つ・ IT 投資と事業成果とのバランスをとる
サービス ・ ポートフォリオは、 サービス ・ プロバイダのサービス全体を見渡して、 どのサービスがどのような価値を提供し、 サービスがきちんと収益を上げるのかを管理します。 これにより、 サービスへの投資の優先度付けが、 しっかりとしたマネジメント基盤の上で管理されるようになります。
また、 相対的に価値の低いサービスから価値の高いサービスへ、 サービス ・ プロバイダ全体の軸足が速やかに移行されるように管理されます。 サービス ・ プロバイダが何に価値を見出すか、 また移行するタイミングがいつなのかは、 サービス戦略に基づく判断によります。 したがって、 サービス ・ ポートフォリオとサービス戦略は切り離すことはできません。

サービス ・ プロバイダのリソース管理
また、 サービス ・ プロバイダの限りあるリソースをどのように配分するかを決めるためにも、サービス ・ ポートフォリオは重要です。
どのサービスにどのくらいのリソースを割り当てれば良いかは、 基本的にそのサービスに対する需要で判断します。 人気があり十分なパフォーマンスを発揮しているサービス （＝価値の高いサービス） は、 その需要の増加に対処するためにリソースを追加で割り当てることが可能になります。 逆にほとんど使われていないサービスは廃止の決定がなされます。 その中間にあるサービスは （ほとんどのサービスはこの部分に該当すると考えられます）、 存続のために追加投資をしてよりニーズの充足を目指すのか、 非効率なところの改善に着手するのかなどが判断されます。

サービスプロバイダの能力開発
サービス ・ プロバイダがどのような 「能力 (capability)」 を持つべきかは、 戦略的な判断が必要です。 なぜなら、 それはサービス ・ プロバイダが提供する価値により決定づけられるからです。 したがって、 能力開発もサービス戦略により推進されます。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )IT サービス ・ プロバイダの能力というと、 IT の専門知識やプロジェクトマネジメントなどのスキルなどが挙げられるようですが、 これは一般的に戦術〜運用レベルの話です。 もちろんこれは地に足のついた議論で、 とても大切です。
ただし、 ビジネスが大きく変わり、 組織の能力も大きく変わるというトランスフォーメーショ
ン （組織改革） が必要となると、 このような個人のスキルセットの充足だけでは全く十分ではありません。 このような状況下では、 サービスプロバイダのパフォーマンスをあげる能力 （コンピテンシー） を再定義するなどの人材管理の側面と、 組織のマネジメント ・ プロセスを変更し定着させるといった組織開発的な側面との両輪で実践する必要があります。

第 4 回目は、 サービス品質と顧客満足度について解説します。
前回は、 サービス戦略とサービス ・ ポートフォリオについて、 その関係性も含めて解説しました。
※末尾に ITIL® のプロセスとの関連を追記しました。

サービス品質にはどのような性質があるのか？
サービス品質には 「実際に提供したサービス」 という観点と、 「顧客が知覚したサービス」という二つの観点があります。 例えば、 顧客がハードウェアの有料技術サポートの依頼をした時に、 サービスプロバイダが部品を交換してすぐに解決したとします。 この時に、 技術的には極めて妥当な処置をしているのでサービス提供内容としては問題ないですが、 顧客は 「重大なトラブルだと思ったのに時間をかけてきちんと診断していない」 と不満を抱くことがあります。
この場合では、 実際に提供したサービスは 「（技術的には妥当な） 部品の交換」 ですが、 顧客が知覚したサービスは 「短時間の診断」 です。
このように、 「実際に提供したサービス」 と 「顧客が知覚したサービス」 は異なることがあります。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )これが、 「SLA の目標値が達成できていることと、 顧客が満足しているかどうかは別物だ」という現象の正体です。
したがって、 サービス品質の管理には、 SLA の測定などによって品質基準に則ったサービス提供ができているかという評価と、 顧客満足度調査によって顧客がサービスをどう認識しているかという評価の両方が必要になります。

顧客満足度がなぜ重要なのか？
顧客満足度の向上は、 サービスに対して肯定的な態度を持った顧客の行動につながります。
これは、 例えばリピート注文につながり売り上げ増に貢献することが挙げられます。 ただし、顧客満足がサービスの売り上げ増に全て直結するわけではありません。 サービスの購入行動は満足度とは関係のない要因にも左右されるからです。 サービスプロバイダにとっては、 満足度の低いサービスは顧客の否定的な態度につながり、 売り上げ減少に直結するという現実の方が重要でしょう。
では、 売り上げに貢献しないなら顧客満足度調査は意味がないと思いますか？そんなことはありません。
顧客満足度は、 「サービスの価値を顧客がどのように認識するか」 という点で極めて重要な情報が得られます。 価値の低いサービスは満足度以前に見向きもされないということを思い出してください （参照記事）。 サービスの価値について常に評価を受けるということは、 サービスプロバイダにとって命綱とも言えます。

期待をどのように設定するか？
顧客満足度は、 顧客が期待していることと、 顧客が知覚したサービスとのギャップです。
期待と合致した経験を得られたと認識すれば満足しますし、 さらに期待を上回れば喜んでくれます。
逆に、 顧客の期待が実際に知覚したサービスを下回ると不満を感じます。
このように、 顧客満足度は主観的なものです。 したがって、 サービスプロバイダの行動としては 「期待の設定」 が非常に重要になります。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )顧客の期待の設定は以下のような様々な活動を通じて行われることになります。
・ 顧客とビジネスについてコミュニケーションをとり、 顧客が何を求めているかをよく知る
・ 顧客に対して自分たちが何に貢献できるかをよく説明する
・ サービス提供内容についての明確な説明
・ サービスレベルの要件を明確にして合意する
・ サービスレベルアグリーメント （SLA） で明確にサービス提供のレベルを合意する
・ サービスレベルの達成度の報告
・ サービスレビューを通じて、 顧客が何に満足し、 何を改善してほしいと思っているかをよく知る
顧客と個別に面談ができるような環境であれば、 上記のようなことを個別に話すことができます。
コンシューマ向けのサービスなど顧客と個別に面談をする機会がとれないようなサービスでは、顧客とどのような関係構築をしていくのかという 「リレーションシップ・マーケティング」 が、顧客満足の改善にとって重要になります。
ITIL® の事業関係管理プロセスで顧客満足度を重要視しているのは、 顧客との関係を構築して顧客満足を獲得することが、 サービスプロバイダにとって成功の鍵となるからです。
ITIL® のサービスレベル管理では、 提供されるサービスのレベルの、 特に 「サービスの保証」に関する顧客満足度に注目します。 また、 SLA は顧客とサービス提供のレベルを事前に合意するものなので、 顧客の期待の設定としても重要な役割を持ちます。

第 5 回目は、 サービス品質の管理で顧客満足と並んで重要な要素となるサービスレベル ・アグリーメント （SLA） について解説します。
前回は、 サービス品質と顧客満足度について解説しました。

サービスレベル ・ アグリーメント （SLA） とは？

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )ITIL® における SLA の定義は以下の通りです。
IT サービス ・ プロバイダと顧客との間で交わされる合意。 サービスレベル ・ アグリーメント
では、 IT サービスについて記述し、 サービスレベル目標値を文書化して、 IT サービス ・ プロバイダおよび顧客の責任を規定する。 （引用 ： ITIL サービスデザイン 用語集）
ここで 「顧客」 という言葉が出て来ますが、 顧客の定義は 「サービスを購入する人」 です。
社内向けの IT サービスの顧客は IT 部門に支払いをすることはない場合が多いと思いますが、その場合は 「サービスに対してお金をだす決定をする人」 と捉えていただければ良いでしょう。
サービスマネジメントの用語では、 日常的にサービスを使う 「ユーザ」 と上述の 「顧客」は別の定義となりますので注意してください。 SLA を最終的に合意する当事者は、 ユーザではなく顧客です。

SLA の目的は？
SLA の目的ですが、 実は SLA 自体に目的があるわけではなく、 SLA を使ってサービス品質を管理することが目的です。 SLA を基盤とした管理活動は、 サービスレベル管理プロセスとして整備し、 実践していく必要があります。
下の図は、 サービスレベル管理の目的を達成するための活動を表しています。 サービスレベル管理プロセスでは、SLA をベースにサービス品質をモニタし、 その結果を分析し、顧客に文書で報告します。 また定期的に顧客とサービス ・ レ
ビュー ・ ミーティングを行い、 識別された改善機会をサービス改善計画に落とし込んで改善施策を実行します。
このように、 SLA を合意することがゴールではなく、 スタートだとすることが重要です。

SLA の中身は？

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )SLA は、 基本的には定量化した目標値を設定し、 この目標値を達成することを顧客に約束します。 したがって、 SLA は達成可能かつ測定可能であることが重要です。
また、 ITIL® で述べている SLA のポイントは以下の通りです。
1. 顧客とサービスプロバイダの合意 （相互承認） となる
2. 許容しうる最低限のサービスレベルについて合意する各項目を以下に補足します。
1 の 「顧客とサービスプロバイダの相互承認」 については、 顧客の責任についても承認をすることになります。
例えば、 ラップトップ PC の貸し出しサービスの場合には、 サービスプロバイダが責任を持って動作保障をする PC を準備することを約束する一方で、 顧客側は 「3 営業日前までに申請する」 というルールを遵守しなければならいといったものです。 顧客は 「今すぐ貸し出して！」と言う方が便利なのですが、 それだと PC をあらかじめ準備しておくコストが発生するので、顧客が少し妥協して 「3 営業日前申請でよし」 と合意することになります。
また、 現実の世界では一方的なサービス提供条件を提示し、 明確な相互承認を必要としない 「サービス品質保証型」 の SLA もあります。 個々の顧客と相互承認を得ることが難しいパ
ブリッククラウド ・ サービスはサービス品質保証型のケースが一般的でしょう （ただし形式的には顧客がサービス提供条件に合意したかたちをとることが多いと思います）。 この場合サービスプロバイダからサービス提供条件を提示される一方で、 約束したサービスレベルが守られなかった場合には返金などのペナルティ条項を設けることが一般的です。
2 の 「許容しうる最低限のサービスレベルについて合意する 」 という点で重要なことは、サービス提供のコストについての考え方になります。 前述の 「ラップトップ PC の貸し出しサービス」の例の場合はコストを考慮して 「3 営業日前の申請」 で合意しました。 しかし、 しばらく運用した後でやっぱり 「すぐに貸し出してほしい」 というようにサービスレベルの要件が変わった場合は、 コスト交渉からやり直しという考え方です。
重要な点は、 顧客とサービスプロバイダの相互の利益を考慮しつつ、 不必要に高いコストをかけないように両者にとって最小限のコストとなるようなサービスレベルを模索していくことです。

2016.11.1、2016.12.17、2017.02.1、2017.03.1、2017.03.15 (５回分 )ペナルティは必要か？
研修などでもよく質問に上がるのが 「ペナルティは必要なのか？」 ということです。 ITIL®
ではペナルティを肯定も否定もしていませんが、 必須ではありません。 むしろペナルティを導入する場合は、 その意義をよく考える必要があります。
ペナルティの目的は大きく二つあり、 一つは顧客の不満の解消と、 もう一つはサービス品質改善の促進です。
顧客の不満の解消については、 不満を緩和することにより顧客の離反を防ぐことができなければ意味がありません。 したがってペナルティの中身は顧客が被った損害をリカバリーできるような、 顧客にとって意義のある内容になっている必要があります。 例えば、 拠点間でデータ転送をするための IT サービスに障害が発生した場合には、 返金をするよりも、 データを保存した物理メディアを預かって先方に届けてあげる方が顧客の目的が達成できているので有意義です。
もう一つのサービス品質改善の促進については、 サービスプロバイダ内部でペナルティ件数を減らそうという動機になるため、 サービス品質改善が促進されるという効果を狙います。
SLA はサービスレベルの維持および改善する基盤とするものですので、 サービス改善活動に結びつくような建設的な合意形成が必要です。 SLA の内容が顧客とサービス ・ プロバイダ間の対立を促し、 乱用されるようなことがあると、 結果的に双方で責任を押しつけ合う関係になりサービス改善とは逆の方向に行ってしまうことがあります。 これは本来の SLA の目的と正反対の結果となるので、 注意が必要です。
ITIL® で基盤となる 「サービス価値管理 (value management)」 と 「サービス品質管理(quality management)」 について解説してきた本連載は終了です。
ITIL® は単なるシステム運用管理の話ではないことがご理解いただければ幸いです。

Copyright © 2008-2021 DIG2 Next Inc. All rights reserved.ITIL® is a registered trade mark of AXELOS Limited, used underpermission of AXELOS Limited. All rights reserved.
The Swirl logoTM is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The ITIL Accredited Training Organization logo is a trade mark of AXELOS Limited. IT Infrastructure Library® is a registered trade
mark of AXELOS Limited