「ITILを柱に」、ITILで日本の生産性向上を目指す Yamatil_です。

MP3は、サービスバリューシステム(以降、SVS)についてお伝える

ITILではSVSについて以下のように述べられている

SVS は全ての利害関係者と協力し、継続的に価値を共創できるようにするシステム

なので、SVS のインプットは機会と需要、アウトプットは価値

プロセスは5つの要素で構成されており

従うべき原則、ガバナンス、サービスバリューチェーン、プラクティス、継続的改善となっている

従うべき原則についてはMP 1で述べさせていただいた

ガバナンスはSVSの方向づけコントロールを行う役目となる

サービスバリューチェーンはSVS の核となるプロセスとなる

サービスバリューチェーンを遂行するために必要な手段としてプラクティスがあり

色々な変化を吸収しながら継続的改善を行い、SVS の精度を線路を鮮度を保つ必要がある

改めて思うが、利害関係者(ここではお客様も含みで考えるべき)で

社会貢献する価値を創出していこう、そのフレームワークがSVSであり

この大枠を脳に入れ、色々なシチュエーションで発展・活用すること

大変有意義な結果を生むのではないだろうか!

次回MP4ではサービスバリューチェーンのことを述べるが、サービスバリューチェーンでは、インプットは需要のみとなっており、機会という要素は含まれてない

なぜそうなのか?について、持論は次回に述べさせていただく

最低、毎週1回の発信を目指していたが、昨今のネーションリーグバレーに

気持ちが入りすぎた影響で、発信が遅れがちになっている点、反省している

「ITILを柱に」、ITILで日本の生産性向上を目指す Yamatil_でした

ごきげんよう!!

 

「ITILを柱に」、ITILで日本の生産性向上を目指す Yamatil_です。

今回はMP#2 サービスマネジメントに必要な4つの側面 をお伝えする

4つの側面の具体的な解説は省くが端的に言うと

1.people 組織と人材

この中には組織としての構造、役割と責任、組織カルチャー

組織メンバーが価値創出という共通の目的を保持してるか、明確なビジョンが

示され、組織の関係者に浸透されているかが大事になる

2.product 情報と技術

サービスマネジメントを支える技術、IT サービスを支える技術

技術の下支えとなる品質、設計思想、セキュリティ、コンプライアンスなども

この要素に含まれる

3.partner パートナーとサプライヤー

組織と人材に似たような要素でもあるが、サービスを提供するための我々と

関わるステークホルダーがこの領域に入ってくる

ここに影響する要素として、1.組織と人材にて述べた組織カルチャーが

パートナーとサプライヤー側のカルチャーと融合出来るかが大事になってくる

最後 4.process バリューストリームとプロセス

目的を達成するために必要な活動、ワークフローをコントロールする手順が

きちんと定義され運用されているかが大事になる

欄外に書いたサービスマネジメントの4つの Pと

今回ここで述べるサービスマネジメントに必要な4つの側面は

密接にリンクすると考えており、その2つを表として整理し、掲載している

 

ここで大事なことはこの4つの側面の全てに適切に対処しないとお客さんの

心に刺さるサービスが提供できないということにからなる

つまり、この4つの側面がバランスよく対処できているのかを監督する役目も

大事であるし、この4つの側面の各責任者が他の側面との協業を意識して

仕事に臨めているのかという点が重要になる

トヨタ生産方式の大野耐一氏は、次のように述べられている

「仕事とはスポーツの陸上競技のリレーのようなものだ」

要は、前の人の仕事をきちんと受け取って、次の仕事の担当者に確実につなぐこと

チームとして仕事を完璧にし、仕事過程の途中に欠陥などを発生させることなく

チームとして正確なものを作るということ

 

では、今日はこの辺で、

次回は、MP#3SVS(サービスバリューシステム)をお伝えする予定

「ITILを柱に!」Yamatil_ からお伝えしました

「ITILを柱に」、ITILで日本の生産性向上を目指す YAMATIL(ヤマティル、今日からそう名乗る事にしました)です。

 

 

 

ITIL 7原則を遂行する中で出てくる問題(あるある)を自分の仕事観点で洗い出してみた

◆価値が、真北の方向でないので、やっていることがぶれる

 ぶれたままで最後までやるか、中止の基準を設け、見直すのか

 そもそも価値のレベル感が、返って細かすぎる

 設定した価値が粗々なので色々な解釈がある

 時代の変化、ステークホルダーの入れ替えありなどで

 何か価値が違ってきているな~と思ってきたら、見直すのが正解ではないか

 (スクラムの要素を取り入れる)

 でも、1回やって、はい変更では、成長もしない

 最低、3回はやってみるのが必要ではないか

 1回目は、手探りでやって2回目につなげる

 2回目は、とりあえずの1回目からの改変なので、それなりに方向性に向かっているはず

 3回目は、現状ベストのはず、これでダメなら、返ってやり方を変える必要があるのでは

◆現状として利用できるものがない

 とはいっても仕事をしているのでから、アナログちっくなもの、ナレッジ化されていないもの位はあるはず なので、それを使う

※SECIモデルを活用してみる

 ナレッジを創出する循環プロセスを表した理論

 暗黙知を形式知に変換

 

 

◆現状はあるが何故か開始できない

 原因(言い訳)を色々と考えてみて、自己問答してみた

 →リソース不足(そこも含めて現状からはじめる)

 →賛同無し(なら一人ではじめてみる)

 →優先度低(優先度を入替、そもそも自分としては優先度「高」と思ったのではじめるんじゃないのか)

 →着目した価値が、事業価値へのリンクが乏しい(言い回し、視点を変えてみたら、何か結びつかないか、1ステップで紐づかなくても、2,3ステップ、中長期にみたら結べるはず)

 →やってやろうとする熱量が足りない(なら、やらなくてよい 熱量を傾けられる事をやる)

 ★自己マインドセットのあり方を変えて、一歩進む

◆反復進化のやり方が分からない

 スクラムの仕組みで無駄を省き、コア部分に集中する

 (ラグビー部では無いが、スクラム勉強中)

◆どの工程からはじめても問題がないということは、

 なるほどな~

 前述した、着目した価値がぶれるとき、着目する価値を再考する意味もあるのではないかと思った次第

 普通、着目した価値は変えないし、目標設定は最初に来るから

 時間が無限であれば良いが、ここに有限(期限)という要素が入ってくると、落としどころが難しくなるね

 

最後に7原則活用シートたるもの勝手に作ってみた

それと、自動化自働化 大野耐一氏の自働化 作りっぱなしではなく人間の判断もその自動化に入れて、

機械を動かすから、働かせる

そして、異常の時だけ、人間様を登場させるのが、自働化

この体制・仕組みは、システム開発・運用保守の運用方法にも使えると感じた

 

今日は、これくらいで終わろうかと思う。

次回は、少し進んで MP#2 サービスマネージメントに必要な4つの側面をお披露目する。

では最後に、「ITILを柱に」