DIG2ネクスト株式会社 鈴木寿夫氏「マルチサービスプロバイダ環境におけるインシデント管理/サービスレベル管理の設計ポイント」を聴いて 20210428_SIAM - Service North 2021 JAPANより

ksr少佐 @ipksr

マルチサービスプロバイダ環境におけるインシデント管理/サービスレベル管理の設計ポイント youtu.be/oW082_k7mBs @YouTubeより 今朝は、これ。鈴木さんの動画が再生回数３９回とは！！これだから、日本のITサービスマネジメント業界は・・・　(´・ω・`)

拡大

ksr少佐 @ipksr

SIAM-ServiceNorth JAPAN 2021の３つめのコマ twitter.com/ipksr/status/1… pic.twitter.com/R3bpJTWhCq

拡大

拡大

ksr少佐 @ipksr

＞マルチサービスプロバイダ環境におけるインシデント管理／サービスレベル管理の設計ポイント twitter.com/ipksr/status/1… pic.twitter.com/9ehaCRbAYC

拡大

拡大

ksr少佐 @ipksr

＞”消費者”はユーザのこと。 twitter.com/ipksr/status/1…

ksr少佐 @ipksr

＞「サービスマネジメントは、組織におけるオペレーティングシステム」です！強調します！ ＞コンピュータにＯＳが必要なように、組織にはサービスマネジメントが必要 ＞サービス時代において全ての組織に不可欠なものであり、もはや投資する、しないの判断ではない。”不可欠”なものである。 twitter.com/ipksr/status/1… pic.twitter.com/GjRZ0B1BVp

拡大

ksr少佐 @ipksr

しかし、現状ではどこの企業、組織にとっても難しい課題となっており、エコシステムの構築は大きなチャレンジになっています。 twitter.com/ipksr/status/1… pic.twitter.com/aQKnwEfevr

拡大

ksr少佐 @ipksr

＞２０２０年４月１日にＳＩＡＭ™BoK ２ｎｄ Editionが発行された。ＩＴＩＬ®４とVeriSM™と適合させる形で。 twitter.com/ipksr/status/1… pic.twitter.com/yWUgPIRJII

拡大

ksr少佐 @ipksr

＞２　消費者とのタッチポイントにおけるバリューストリーム すずきさんの手書き・・・　味わい深いｗ ＞バリューストリームで考えると非常にあたりまえ。 twitter.com/ipksr/status/1… pic.twitter.com/mocq5ZYkWJ

拡大

ksr少佐 @ipksr

全体のリードタイムを短くすることが消費者への価値。バックエンドに多くの関係者がいるのであれば、マルチプロバイダ環境のエコシステムを構築しなくてはならない。当然、窓口はひとつ。 twitter.com/ipksr/status/1…

ksr少佐 @ipksr

＞３消費者サポート対応のバリューストリームの設計ポイント（インシデント／障害／エラー対応） この流れには、操作方法の問い合わせ、仕様の確認、インストール依頼、標準的な変更要求などの”サービス要求”も含まれるべきだと思う。なんなら、システムへの要望、グッドメッセージの受付も。 twitter.com/ipksr/status/1… pic.twitter.com/kpYuIgZppA

拡大

ksr少佐 @ipksr

＞◎設計のポイント 　１．待ち時間を削減する 　２．ハンドオフを削減する 滞留、待ち時間はムダである。 twitter.com/ipksr/status/1…

ksr少佐 @ipksr

＞インシデント管理とリアクティブな問題管理の間にはハンドオフが発生してしまう。 「プロアクティブな問題管理」のみ実装する (ΦωΦ)！！？？　できるのか！！？？ twitter.com/ipksr/status/1… pic.twitter.com/FeG7MJtlFv

拡大

ksr少佐 @ipksr

＞”問い合わせ”のバリューストリームにはインシデント管理とリアクティブな問題管理が混在する。ここがITILv3の弱点！あくまでもプロセスベースなのでハンドオフが多くなる。プロセスサイロもできてしまう。 再発防止／未然防止の観点、プロアクティブな問題管理によってインシデントを減らしていく twitter.com/ipksr/status/1… pic.twitter.com/0wGwcwvPrx

拡大

ksr少佐 @ipksr

＞ポイント！！　管理するために測定できるようにすること インシデントのハンドリング方法は、詳しくはつぎのセミナーでｗ　残念。 twitter.com/ipksr/status/1… pic.twitter.com/IzuTiEIEfQ

拡大

ksr少佐 @ipksr

＞４　消費者サポート対応のバリューストリームの設計ポイント（問い合わせ対応） あぁ　こっちが”サービス要求”かな。 ユーザからの連絡のうち、約８０％は問い合わせだって。 twitter.com/ipksr/status/1… pic.twitter.com/TRXhVbuBGC

拡大

ksr少佐 @ipksr

＞プロアクティブな問題管理で削減できるパイはたかだか２０％なので、本質的には８０％を削減する活動のほうが効果があるはずだしそれをやるべき。 SHIFT LEFT!!　よりユーザの手前で解決する。奥に入らせない。 ここがナレッジ管理。問い合わせをへらすにはナレッジ管理。 twitter.com/ipksr/status/1… pic.twitter.com/mAeR4Tq1Qn

拡大

ksr少佐 @ipksr

＞「ナレッジ戦略／ガバナンスはＳＩＡＭモデルのＳｉの責務です」 ＞◎設計ポイント！ 　消費者サポートのバリューストリーム内にナレッジ作成の流れを含める！　 極端な話、インシデントレコードをユーザも参照できればそれだけで解決しそうだし、参考情報も見つけられるかも。 twitter.com/ipksr/status/1… pic.twitter.com/Bb7dMSBeUg

拡大

ksr少佐 @ipksr

ここがＳＩＡＭ！マルチプロバイダ管理の肝。 各サービスプロバイダにナレッジを埋もれさせるのはもったいないし非効率。サービスインテグレータを構成する全員が参照できるようにするべき。 twitter.com/ipksr/status/1…

ksr少佐 @ipksr

＞まとめ　設計ポイント ＩＴＩＬｖ３が時代に合っていない理由は、顧客視点でないところ。 twitter.com/ipksr/status/1… pic.twitter.com/6DHyBx5gMt

拡大

ksr少佐 @ipksr

＞ＩＴＩＬ４が生まれた理由は、ｖ３ではプロセスサイロが発生してしまう。インシデント管理はそれだけ。問題管理はそれだけ。といったように。 ＞サービスマネジメントの組織変革が求められている twitter.com/ipksr/status/1… pic.twitter.com/BbSBRQADNA

拡大

ksr少佐 @ipksr

プロセスの導入ではなく、 組織的チェンジマネジメント（ＯＣＭ） 　→　ＡＤＫＡＲの活用 組織的ビヘイビアマネジメント（ＯＢＭ） が重要。 次回予告！！　あしたは、これも聴きなおそう 　やはり、１回聴いただけじゃおぼえないや。 twitter.com/ipksr/status/1… pic.twitter.com/DdH2S5WWF6

拡大