2015年2月18日水曜日

ITIL運用によるPDCA改善
~一貫性を保つサービスレベルコントロールマトリクス~

こんにちは。鈴木です。

今日は、情シス部門が事業部門に、情シス子会社が親会社にといったITサービスを利用する側へITサービス提供側が月次や半期などで報告にスコープを当てて、発生する課題や改善の手法をご紹介します。

昨今、私が様々なお客様に伺うと、それぞれ以下のような課題がありました。
 
≪ユーザ組織(報告受ける側)

・報告が分かりにくい

・細かいデータが大きく要点をつかみづらい

・定量的な評価ができない

ITサービス提供組織(報告する側)

・定量的に改善しているといった点を報告できない

・データソースが分散しており、集計が大変

・蓄積されたデータでは分析ができない

・現場ではデータ登録作業負荷が大きい

・現場がIT視点に偏り、ユーザ視点にかけている
 

このような双方に課題が存在し、本来PDCAを回すための報告が、誰にとってもメリットが出ない状況を発生させています。




このような課題を発生させる原因として考えられるのは、どの様にPDCAを回していくかの設計がされていないこと、現在自分が行っている業務が最終的に顧客にどう影響を与えているかが現場では見えないことが挙げられます。


本来の報告目的から担当者が自分で実施している業務までの紐づきがわかり一貫性を持たせることが成功のカギになると思います。


それを解決するために、今回はサービスレベルコントロールマトリクス(以降SLCMと表記)を使ってみたいと思います。かなり長い名前になってしまいましたが、リスクコントロールマトリクス(RCM)を応用して考えたものです。

リスクコントロールマトリクス参考Web
http://ja.q-bpm.org/mediawiki/index.php/RCM

SLCMを作成する上では大きく4つのセグメントで考えていきます。


 
まずは報告目的です。単純に現状を把握するだけにするのか。何らかの改善を図りたいのかによって報告目的が変わります。そして報告目的に応じて報告事項も異なります。一度決めて終わりではなく、定期的に報告目的や報告事項の見直しが必要になります。おすすめとしては、以下のサンプルのようにすべてをITILメッシュにしなくてもよいと思いますが、ITILのプロセスにそって目次を作ると、わかりやすく、この後に説明するデータソースとの関連付けがしやすくなります。

報告例

次に報告目的、報告事項に基づいて、KPIを設計していきます。ユーザの対応満足度を上げる為に一次回答対応期限を設けた場合などは、その遵守率など、KPIに設定していきます。
 
KPIまで決まったら、それを計測するためのコンテンツの洗い出しを行います。以下は関連性の概念図ですが、どのKPIをどのデータソースのどの項目までつながっているのかまで明らかにすることが重要です。

報告までのデータの一貫性概念図




設計の流れは、報告からブレイクダウンしていく形になりますが、報告する上での情報の流れはデータソースからKPIがどうなっているのか、それを報告事項として記載していくという逆の流れになります。



これをスプレッドシートなどで表にしてまとめていくと、このように顧客視点の目的から現場の作業まで紐づけることができ、報告事項などを変更する際も、その影響を明らかにすることが可能です。

サービスレベルコントロールマトリクス(SLCM)イメージ


まだ、多くの企業はデータソースを統合管理できておらず、データを抽出してから多くの労力をかけているのが現状です。アプリやインフラで組織が分かれていることも多く、データソースも分かれていることが多い為、なおさら整理することが難しくなります。

もし皆さんも、報告に課題を感じ、PDCAがうまく回っていないと感じることがありましたら、ITILベースの報告様式とSLCMを用いた目的に対して一貫性を保つことで、顧客と現場の思いを繋げ目的志向のマネジメントを目指してみてはいかがでしょうか。




0 件のコメント:

コメントを投稿