なにしてみよっか

サービスってなんだろな?を細々と。基本マニアックなネタが多いです。トヨタ生産方式を信奉してます。某製造業の営業と社内SEをやってました。

KPI/SLA/SLOの関係性を考える 5/4(延長) -運営が、経営・運用の組織に動的に関与してもらう-

こんにちは。前回の記事で、ITサービスマネジメントは経営である。という話で締め括りましたが、さまざまなご指摘を頂戴しました。そのため、再度整理すると、自分自身が経営と運営を明確に切り分けできていないなと痛感いたしました。そこで、延長戦として、改めて経営と運営とを明確に定義します。

その上で、前回の記事はそのままに、改めて本稿で改訂いたします。

なお、旧記事は(未改訂版)と注釈を入れます。

KPI/SLA/SLOの関係性を考える4/4 -KPI/SLA /SLOの定義は「経営」- - なにしてみよっか

 

では、本稿を始めます。まず、前回の記事、さまざまな方からご指摘を頂戴したのですが、そのご指摘を並べてみると人のおっしゃっている言葉の定義が微妙に違うことに気がつきました。つまり、人によってイメージしているものが違う。実際ご指摘をくださった方々もそれぞれの立場での発言を行なっていて*1、どう定義すべきなのかについて議論をしていただいていました。それらを眺めてまとめ、おおよそ何か特定の目的を果たそうとした時どのような役割が必要なのか(つまり登場人物の全体像)が見えてきました。

それが図1:経営・運営・運用の役割(ロール)定義です。

ざっくり言えば、この3つの役割が必要です。

図1:経営・運営・運用のロール定義

商人に例えていますが、大切なことは太字にした部分です。儲けることが大切なのではありません。「(戦略を)決定し定義する」「(戦術を)実行し(戦略を)改善する」「(作戦を)実行し続ける」この3つが必要であるということです。要するに、「決定」「定義」「実行」の3つをそれぞれの立場において実行するということです。儲けるということは、ここでいうと目的にすぎず*2解き明かしたいポイントではありません。

ここで大切なことは、KPIやKGIなどの初期定義とKPIの改善は別のロールで行うものであるということです。ここをITSMとして混同しておりましたが、ここは明確に分けなければいけないところでした。

それと同時に、杓子定規に必ず分けなければいけないものでもない、ということも勘定に入れておかねばなりません。つまり、自社が提供しているサービスは1つだと定義するのであれば、経営と運営は同一で合っても構わないということです。(旦那と番頭を分ける必要がない)ただ、これってほぼ例外に近いと思われます。正確に言えば、スタートアップ企業限定かなと。明確な基準を申し上げることは難しいのですが、最大でも10名程度の社員規模で、サービスとしては特定のペルソナに絞ったサービスを提供している、、、というようなイメージです。

いわゆる中小企業と言われる規模であっても企業規模によらず、組織として複数組織を持っている企業は、最低でも経営と運営を分けた状態を作るべきであろうと思います。組織や人として完全に分けろ、とまでは言いませんが、少なくともロールとしては分けていて、組織または人に集約しているという状態が必要ではないかなと。恐らく、ここを明確に分けていない組織がそのまんま大きくなると破綻するんじゃないかなと。

 

閑話休題

今回改めて、ITSMとして、「経営」「運営」「運用」を定義してきました。 *3

では、それぞれのITSMの指標が「経営」「運営」「運用」とどのように関わるのかを改めて定義しましょう。それが「図2: (筆者の考える) ITSM運営時における各指標への関わり方」です。

図2:ITSM運営時における各指標への関わり方

なお、「自分はどこ(例えば、「運用」)を担当している、だからSLOに責任があるのだ」と思い込まないでください。これら3つの登場人物はあくまで今回定義したロール(役割)に基づいて幅を持って作成した下敷です。

この下敷の使い方は、「自分の役割」を定義するものではなく、それぞれの「サービス構成組織」を定義するための羅針盤として考えてください。

説明が難しいため、「図3:フェーズごとに組織の関与レベルを調整する例」をご覧ください。

図3:フェーズごとに組織の関与レベルを調整する例

このようにサービスを設計しているタイミング、サービスを運営しているタイミング、サービスに変更を加えている(新たな開発を行なっている)タイミングにおいて、経営と運営と運用それぞれの立場の関わり方が変化しています。お伝えしたいのはこういうことです。

つまり、図2は図1のような責任と権限を持った経営と運営と運用が揃った時に一般的なロールとして下敷きを置きつつ、図3の示す通りに各組織がそれぞれのフェーズで指標に関与するということを表しています。つまり、下敷(1/2)をベースに自分たちのロール設計(2)を行い、サービスのフェーズごとにそれぞれの役割を柔軟に変えながら指標に関与してゆく(3)ということです。(4:指標への関与とサービス運営の一連の流れ)

指標への関与とサービス運営の一連の流れ

さて、話があらぬ方向に向かってしまいましたが、結論としましては、「経営組織」と「運営組織」と「運用組織」。その3つがあるとしたとき、ITSM組織は運営組織です。しかし、運営組織だからといって、運営組織として自らを枠にはめるのではなく、そのサービスのフェーズ毎に、関係する「経営組織」「運用組織」と調和させながら、それぞれの指標にその意思を反映する。そうすることで最適な指標を維持し続けることができる。そういうことではないのかな。と考えます。

今回非常に悩みました。。正直なところ、一つテーマで扱うものではないと思いましたが、さまざまなご指摘をいただいたことがきっかけとなり、経営と運営の違いを改めて真剣に考える機会に恵まれたことに感謝いたします。

 

*1:全然関係ないですが、この自覚した状態で話せる、つまり、前提がズレている状態で喋っていると全員が自覚している場というのは本当に良いですね。あげあしを取る人もいなければ、炎上もしない。つまり心理的安全性が高い。こういう本質的な「寛容」さが今後求められる時代であると本当に思います。

*2:目的は大切なものなのですが、この文脈においては、大切ではないという意味です。ここで定義したいのは、あくまで「経営」「運営」「運用」とは何者か?ということで合って、この3つが何を目的に集っているのかが重要ではないということです。

*3:この「経営」「運営」「運用」の定義については本当に散々悩みました。本来的に経営にDirection(方向づけ)の機能を入れるならExecution(遂行・実行)はどう位置づけるかとか、ではGovernance(統治)はどうこれらの要素を補強するのかとかですね。しかし、これら「Governance(統治)」「Execution(履行・実行)」「Direction(方向づけ)」「Management(管理・運営・経営)」「Operation(運用)」や、日本語としての「経営」「運営」「運用」といった言葉達はそもそも言葉を使う人の理解や定義によっておおよそその意味が変わってきます。そう考えると、ITSMとして、これらの言葉をどうか使うべきかに注力すべきであって、経営の本質とはなんぞやとかそう言うことを議論したいのではないなと。一周回って、ITSMのための「経営」「運営」「運用」の定義を整え、あとは、定義した役割に基づいて、組織設計をするのだと考えました。この組織設計は、その事業体がどう意思決定をしたいのか、であるとか、そこに集う人間のスキル、素養、マインドセットによって「最適」な状態は変わります。ロールにピッタリハマる人を探す/集った人たちのアセットをベースにロールを設計する。どっちを選んでもいいよなと考え、アメーバ的に変化し続けることで最適な指標を維持するという考えに至りました。

KPI/SLA/SLOの関係性を考える4/4 -KPI/SLA /SLOの定義は「経営」-(未改訂版)

こんにちは。ついにやってまいりました。最終回。KPI/SLA/SLOの関係性を考えると最後は経営に行き着く。という話。これを直感的に理解できる部分もあるのですが、その直感をちゃんと説明します。

まず今までの図を再度更新し、KGI/KPI/SLA/SLOの関係性を定義し直しましょう。(図1: KGI〜SLOの全体(更新版))

図1: KGI〜SLOの全体(更新版)

 

定性的な経営理念や経営目標からKGIを起こします。このKGIは、顧客組織(いわゆるユーザ企業)とサービス提供組織(いわゆるベンダ)それぞれのKGIになります。強引に言えばこれ、各事業体の経営計画や目標利益になります。

そのKGIに対して、各組織を運営する長が咀嚼した結果、どのように組織を運営するのか、その組織の目標を何とするかを合わせて、「サービスとしてのKPI」を統合して定めます。そのサービスとしてのKPIに関して全責任を負うのは、「サービス構成組織」(注: 当ブログのみの用語)です。そのサービス構成組織が定めたKPIを分解することで、サービスとしてのSLAが設計されます。そして、既存のツールから定義されたSLOをそのSLAを達成する具体的な目標として紐付け、可視化できるようにする。その時、可視化できないSLAがあったとしても、KPIを説明できるようであれば、一時的には放置する。

今まで説明してきたことは上記の通りです。

 

では、なぜ、これが経営なのでしょうか?そもそも経営とは何なのでしょうか?手元の辞書を引くと、次の記載がありました。「事業目的を達成するために、継続的・計画的に意思決定を行って実行に移し、事業を管理・遂行すること」

この事業がいわゆるサービスな訳です。この図にあるサービス構成組織とは、簡単に言えば、そのサービスを事業とみなし、目的(関連事業体の経営目標やKGI)を達成するために、継続的・計画的に意思決定を行って実行に移し、サービスを管理・遂行することなのです。

サービス管理と経営、一緒ですよね?

つまり、SLAやSLOを定義することは、サービスの経営計画を決めること。その経営目標を達成するためにKPIを要素分解し個別具体的な目標値を設定し運営することなのです。

そう理解して再度図を眺めると一つのことが理解できると思います。KGI/KPIがあり、その上でSLA /SLOを定義する理由。それは、複数の事業体が協働するが故に起きることなのだと。ちょっと極論ですが、一つの事業体、つまり、完全に統一された一つの会社で全てが完結するのであれば、実はKGIは一つしかなく、結果、サービスとしてのKPIも一つないしはかなり小さい幅で統一できます。つまり、KPIについて幅を持って定義する必要性はありません。しかし、現在において、サービス提供企業はますます増え、コラボレーションする、協働する、サービスを利用するなどの関係性が高まっています。アレな話ですが、パブリッククラウドを一切使っていない一定規模以上の企業はいないでしょう。*1

 

これの意味するところ、サービス構成組織は、自分たちのサービスの内容を把握し、今後の変化に対応するために、KGIを取得していかねばならない。これはつまり、こういうことです。

例えば、Microsoft社が、ライセンス料を値上げするのは、彼らのKGIが変化したからです。KGIが変化し、クライアント先に対する重みづけ(……という言い方はあれかな?優先度というべきか、、、)が変化したためです。それに対応するために、自分たちのサービスのKPIを変える。そういうことなのです。*2

 

サービスとしてのKPIは、結局のところ、サービスを事業と捉えた際、サービス提供組織のKGIをまとめて、自分たち(サービス構成組織)のKGIとして定義する行為だということです。したがって、サービスとしてのKPIを定義し責任を負うサービス構成組織の長になる人物とは、サービスの経営者になります。では、このサービス構成組織の長は誰がなるべきなのでしょうか?正直に申し上げます。「わかりません」。これは、「解がない」のではなく、「場合による」からです。このサービスに対して最も責任を負うという意味では、「発起人」に相当する方がなるべきなのでしょうが、そもそもこの発起人を誰がするべきかがわからないのです。いくつか事例を考えてみましょう。

 

標準PCサービス(社員共通サービス)の場合、経営者として相応しいのは、いわゆる情報システム部門と言えるかもしれません。なぜなら、事業部門から見ると、各種ガバナンスにより定義された安心安全なPCで業務を遂行したいのであって、これら標準PCサービスでなし得たいことは自分たち固有の要件としてありません。この標準PCサービスを構成する各種リソースを提供するベンダは、このサービスを運営しなければならないわけではなく、その提供する各種リソースを提供することによる対価を得ることが目標です。したがって、サプライヤが相応しく、経営者ではありません。この標準PCサービスの共通的な目標を定義できる存在としては情報システム部門が相応しいと言えます。

では、特殊PCサービス(部門固有サービス)の場合、経営者として相応しいのは誰でしょうか?情シスでしょうか?その要件をもつ事業部門でしょうか?
情シスとしては、共通PCには共通的な目標を立てる必要がありますが、部門固有PCについては、自分達のプロセスを変えずにサプライヤとして関与するということもできます。逆に、自分たちにとって追加の資金を得る、または他のKGIで未達となる目標の穴埋めとしてイニシアチブを取り、プロセスを変えて自分達がPCサービスの経営者として追加費用を頂いて管理するという方法もありうります。事業部門とて同様です。自分達の目標にふさわしいPCを調達し自分達で管理運営する(自分達が経営者となる)という方法もありますし、固有PCのガバナンスを含めて面倒を見てもらうことで追加の人員を雇う必要がないと考え、追加の費用を払って特殊なサービス形態を持って自分達が顧客として立つこともできます。

お気づきでしょうか?ITIL4の4つの側面、「組織と人材」「パートナとサプライヤ」「プロセスとバリューストリーム」に言及しています。さらに言えば、6つの外部要因にも言及していますよね。

このように、それぞれの4つの側面を考えた際最も自分達の戦略にとってふさわしい方法を選択する必要があるため「場合による」のです。裏返すと、ITIL4の4つの側面、7つの原則、6つの外部要因で状況を整理し分析できる人を懐刀に置いた人がサービスの経営者にふさわしいのかもしれません。

さて、四回わたって解説してまいりました。SLA/SLO。何らかヒントになることはあったでしょうか?チケット化することは大切なのですが、チケットに全ての情報をためることは無謀です。(現場が疲弊します)第三回で説明したとおり、7つの原則に従いKGIからSLOまで落とすことも大切ですが、今回説明したとおり4つの側面に従い自分達の戦略を決める必要もあります。ITIL4のフレームワークを使いどんなSLA/SLOを決めてゆくべきか、ITIL4を羅針盤として、SLAとそれを支えるSLOを決めてゆく。テーラーメイド化されたITSMを作り上げ、サービスを経営していって欲しいと思います。

*1:というか、中小零細企業こそパブリッククラウドは使って欲しいのですけど。というか、実態としては使っているのですけど。例えば、弥生会計クラウド(ソリューション)とか。ああいうものって、実態としてはAWSとかOCIとか使ってると思うのですよ。

*2:ちょっと例えてみましょう。こういうことです。

社員向けの共通サービス(MS365)があったとします。この時、KGIとして定めるべきは、自社のKGIを分解し自分の組織の目標として定義したもの、とともに、MS365を提供するMicrosoft社のKGI、またはそのKGIに基づいた自社への目標を理解しておく。これ、ものすごいことを書いているように見えますが、みなさん来年度予算を作るときに普段やってらっしゃいますよね。ですので、意識を変えるのです。来年度の予算だてという行為そのものがこのように各社のKGIをすり合わせて「共通サービスのKPI」に落とし込む意識を持つ。これを思わずに。予算申請をしても業務は完了するのですが、仕事は完了しません。KPIとして定めきっていないため、変化に対応できなくなるでしょう。

KPI/SLA/SLOの関係性を考える 3/4-サービスとしてのSLA/SLO-

こんにちは。本日は続いての第三回。サービスとしてのSLA/SLOを考えましょう。まずはお馴染みの再掲。

図1:理想的なKPI/SLA/SLO

今回は、この図の右側、「対象サービスにおけるSLA/SLOの決め方」です。断っておきますが、本日論じるのは、SLA/SLOの個別具体なパラメータとして何が適切かということを示しません。従って、SLAとは稼働率XX%になっているべきで━━━━というようなことを記載いたしません。(ただし、結果的に稼働率SLAになる可能性は否定しません)

本日論じるのは、「SLA/SLOはどうやって決めていくのか」というプロセスを論じます。そのプロセスの元になっている背景や前提を理解いただく必要があり、そのために第二回がありました。

では、始めます。

前回までで、サービスとしてのKPIを定めていくプロセスを論じました。関係する最大組織(ユーザ企業、ベンダ企業)の経営理念やKGIを把握し、最大組織の中で関連する組織(要するに部・室)のKPIを把握する。その上で最大組織の中で関連する組織の長(簡単に言えば、各部長)がそれら経営理念やKGIをどのように捉えて組織を運営していっているのかをインタビューし「真の関連組織のKPI」を把握する。その上でそれらをまとめて、「サービスとしてのKPI」を導き出す。ここまでを説明してきました。

さて、そうやって導かれたサービスとしてのKPIを今度はSLAやSLOという個別具体的な数字に落とし込んでいかねばならない。その方法、つまりは方程式を論じていきましょう。

おっとその前に、今までどの教科書にも定義されていない新たな言葉を定義させてください。

「サービス構成組織」=顧客組織とサービス提供組織(要するにベンダー等)の集合体

サービスを提供するために各組織のKPIを持ち寄り、最終的にサービスとしてのKPIを定めましたね?それの成果の責任や説明責任を負う単位です。いわば「サービスとしてのKPI」を定めた張本人(またはそれに準じる組織)です。ここで勘違いして欲しくないのは、サービス構成組織のサービスと、サービス提供組織のサービスは違う「サービス」であるということです。

サービス構成組織のサービスは、「サービスとしてのKPI」になります。それに対し、

サービス提供組織のサービスは、「顧客組織に提供するサービス」を指しています。

これは、ITIL4で言うサービス関係を理解していないと勘違いしやすいかもしれません。本論とは異なりますので、こちらは脚注に記載します。*1

さて、サービスとしてのKPIが定まりました。そこからSLAに落とさねばなりません。そして、SLAからさらにSLOを考えねばなりません。この関係を表したものが図2:KPI/SLA/SLOです。

図2:KPI/SLA/SLO

では、ここで質問です。この時KPIにはどのような業績の指標が書かれているべきでしょうか?

筆者の場合であれば、下記のように考えます。

  • 当該サービスが標準PCサービス(いわゆる共通系のサービス)の場合:運用費用が1台あたりXX円以内であること、運用費用がXXX千円以内であること
  • 当該サービスが人事評価支援サービス(例えばカオナビとか、HRBrainとか)の場合:運用費用が管理職一人当たりXX円以下であること、管理職の人事評価業務に費やした時間がXX時間/年削減されること

お気づきの方もいるかもしれませんが、要するに期待効果なんですね。ちょっと逆説的ですが、KGIと経営理念に基づき組織を運営している長のインタビューを通して、それらを実現させるための具体的な目標値、それがKPIになります。なので、ふわっとした定性的な概念や状態を示すのは、経営理念とKGIまでで、それをどう解釈しどのような数値にするのか(KPIとして定めるのか)は、長が意識し、それを運営者がダイレクションし、運営者とサービス提供組織が決めていく。その結果、サービスとしてのKPIが決まる。

では、このKPIをどのようにSLAに落とし込むのか。このKPIを分解するんです。そして、ここも大切なのですが、SLOからSLAに向かうのです。(図3:KPI/SLA/SLOの構成)

図3:KPI/SLA/SLOの構成

KPIはSLAに分解されるのですが、SLOはSLAから落とすのではなく、SLOからSLAに向かって紐づけられます。

結果的にどのSLOとも紐づかないSLAが存在する可能性は出てきますが、それは受容します(左から3番目のSLA)。ただし、全てのKPIは何らかのSLOとリンクしている状態にしなければいけません。つまり、可視化の確度が低いのは受容しても、可視化できない状態はダメです。

なぜ、SLOに紐づかないSLAを許容するかというと、7つの原則*2を意味します。特に「3.フィードバックを元に反復して進化する」「5.包括的に考えて取り組む」に従うためです。図3をよく見てください。確かにSLOに紐づかないSLAが1つあります。しかそのSLAの元となるKPIは別のSLAでどの程度の確度になるかは分かりませんが、ある程度の可視化はできる。そのような構成になっています。つまり、全てのKPIは今のままでも何らか情報を取得し把握することはできる。もし仮に、このSL Aに紐づく目標を作り定義しようとすると、運用現場の負荷が増し、運用手順が増えたり、記録のための仕事(もはやブルシットジョブ)を増やすことになりかねない。それは、果たして本当に必要なものなのでしょうか。今のままでも十分FBが得られ、反復できるのであれば、無理やりSLOを作るのではなく、このSLAが足りないKPIについては参考情報、または(他の2つに比べ)確度の低いKPIとして扱った方が全体的な負荷がとれた運用体制となります。

さて、ここで勘の良い方は気がついたと思います。SLOとは、運用管理ツール(SNOWとかRedmineとかJiraとか)や監視ツール(Zabbixとか)で取れるデータなのです。現状の取れるデータから始め、FBをえて、反復して、その上で、今取れていないSLAがやはり必要となれば、その(SLO取得のためにツール構築を行うという投資の)正当性を示し、K GI達成のための見通しを示し、そこからSLAの根拠となるツールを構築するのです。それまでは放っておいていいのです。

さて、これで、一度左側と右側、それぞれについて解説してまいりました。一度まとめます。(図4: KGI〜SLOの全体の構成)

図4:KGI〜SLOの全体の構成

前回お示しした通り、経営理念やKGIを道具として、サービス提供組織ごとのKPIを導き出します。その上で、サービス構成組織として当該サービスに求められるKPIを導き出します。

今回ご説明した通り、サービス構成組織のKPIをSLAレベルに分解します。そして、今手元にある道具から導けるデータをSLOとしてSLAに紐づけます。最後に、手元にある道具から定義したSLOが、サービス構成組織として当該サービスに求められるKPIに紐づいているかどうかを確認します。この際、SLOに紐づかないKPIがあった場合は、対処しなければいけません。しかし、全てのKPIが何らかのSLOに紐づいているのであれば、中に浮いたSLAについては一旦横に置いておいて構いません。

 

いかがでしたでしょうか?これで、KPI〜SLOに至るまでの全体の関係性に関しては終わりとなります。次回最終回、第四回:KPI/SLA/SLOの関係性を考える4/4 -KPI/SLA /SLOを定義することは「経営」である-に続きたいと思います。

*1:例えば、ここに、企業標準PCを提供し、PCを維持し、サポートまでを行う「標準PCサービス」があったとしましょう。

この場合、サービス構成組織の提供するサービスは「標準PCサービス」になります。対して、サービス提供組織のサービスは、この「標準PCサービス」を構成する各種サービス、つまり「PC購買サービス」「PCキッティングサービス」「PCサポートサービス」などの各種サービスを提供するベンダ、ないしは組織になります。よってもって愚直に記載しますと、「(カタログ化された)サービス(を)構成(する)組織」が「サービス構成組織」。「(カタログ化されたサービスを提供するためのリソースとなる)サービス(を)提供(する)組織」が「サービス提供組織」となります。そしてこのような書き方をするのは、ITI4の一般的マネジメントプラクティスの「ポートフォリオ管理プラクティス」並びにサービスマネジメントラクティスの「サービスカタログ管理」を参照しているためです。サービス提供組織をリソース提供組織としても良かったのですが、ITIL4の概念として「サービス関係」がうたわれており、そもそもベンダ組織から見れば、顧客組織をユーザとして提供しているサービスです。捉え方の違いにすぎません。顧客から見ればリソース、ベンダから見ればサービス。視点の違いをどう入れ込むかに苦心し、最終的に「サービス」の捉え方の違いを説明し全体整合性をとるべきであると結論づけました。結果わかりにくくなるというか混乱を招いている気もしないではありません

*2:7つの原則は「1.価値に着目する」「2.現状から始める」「3.フィードバックを基に反復して進化する」「4.協働し可視性を高める」「5.包括的に考えて取り組む」「6.シンプルで実践的にする」「7.最適化して自動化する」です。この“中に浮いたSLA”問題は、確かに35で整理できるのですがそれを補強する素材として、126そして、ツールに対して投資するという部分は7で説明できますよね。やはり7つの原則は「原則」なのです。

KPI/SLA/SLOの関係性を考える 2/4-組織毎のKPIのアライン-

どうもこんにちは。さて、第二回。組織毎のKPIのアラインについて考えましょう。

まず再掲

前回の図ですが、今回はこの左側、つまり、KPIをすり合わせる計算式について考えましょう。

早速ですが、この図を見て、「わかりました!では、自社のKPIと顧客のKPIを足せばいいんすね?」と延髄反射で顧客組織に突撃はしないでください。

おそらく「KPI教えてください」と言ったとして、そして顧客組織にKPIが実際にあったとして、それは、「擦り合わせなければいけないKPI」ではない可能性が高いです。そう思う理由は脚注に書きます。*1

筆者ならどうするか。まずは、抽象的(教科書的な汎用表現として)に。

先ほど申し上げましたように現行のKPIを教科書的に定めたKPIだと思って突き進むのは得策とは言えません。疑ってかかる必要があります。教科書的なKPIとは「サービス提供組織、または顧客組織の最終目標を達成するために達成しなければならない主要な業績の目標」。それに相当する本質的なKPIを求める必要があります。

そのためには、それぞれの組織の最終目標について理解しておかねばなりません。それは経営理念とKGIになります。ここが「KPIの背景」です。そこを収集し明文化する。それが中核を担います。

では経営理念とKGIはどのように収集できるのか。経営理念は簡単ですね。Webサイトに大体書いてある。そうでなくともIRサイトや株主総会資料を見れば大体書いてある。あとは肉付けとして、その「経営理念」をステークホルダーがどう解釈しているのかをインタビューすれば良い。

ここ、実は大事です。

経営理念だけを引っ張ってきて「経営理念がこうなのだから、ゴールはこうでしょう!」と顧客に発表するのは悪手です。「正論パンチ」と呼びます。経営理念を中心にしつつも、それぞれの組織においてはどのように解釈されているのか、それら経営理念を人が解釈し人が組織を運営します。従って、対象組織に属していない人間が、Webや総会資料上に書かれている経営理念のみを読み解いてあなた方の経営理念はこうですよね?だからKGIはこうですよね?というのは、「越権行為」に他なりませんし、人によっては無礼だと感じる人もいるかもしれません。(逆に当たれば、「良くぞそこまで考え抜いてくれた」になるかもしれませんけど、それってギャンブルではないですかねぇ)なお、これはベンダー側にも言えることです。

つまり、KPIをすり合わせる、という行為は、顧客組織とサービス提供側組織それぞれの経営理念とKGIとそれを補強するために管理単位の長と会話し「このサービスにおけるKPI」を決める。こういうことなのです。(図2:KGIとKPIの関係性)

KGIとKPIの関係性

もう少し具体的にご案内します。事例として、

  • 2つのシステムで構成される1つのサービスの開発と運用を決めるにあたり
  • 「ユーザ側企業」と「ベンダ側企業」の2社があり
  • ユーザ側には「事業部門」「情報システム部門」、ベンダ側には「開発部門」「運用部門」の4組織がある
  • 筆者はコンサルタントとして「ユーザ側情報システム部門」に雇われている

という前提で考えてみましょう。

これを示しますと図3:KGIとKPIの関係性(具体事例)になります。

図3:KGIとKPIの関係性(具体事例)

コンサルタントである筆者は、ユーザ側情報システム部門として自組織(情シス)のKGIとKPIの粒度と内容を示し、他3部門に対して問いかけます。「各組織のKGIとKPIを教えてください。粒度を揃え、一度整理いたします」

そうして集まった各組織のKGIとKPIを情シスのKGIやSLAの粒度に合わせて修正するよう修正作業を行いつつ、各組織の長にインタビューします。インタビュー内容は1点。「あなたは、自組織がどうなることを期待しますか?」です。長は、いわば「自社(≠自組織)の経営目標やKGIを咀嚼し自組織の人員で達成することを考える」役割です。明文化されないKGIやKPIに対してもっとも明確な解を持っている存在です。

そうして、1つのサービスを提供する責任を負う(おそらくは)事業部門担当者に説明します。「このサービスは、XXXという目的を果たすために今回構成され、4組織が集います。それらサービスとサービスを構成する組織とあなた(事業部門のサービス担当責任者)が達成するKPIは次のとおりと定義したいと思います。……」

いかがでしょうか?イメージつきますでしょうか?各最大管理組織(企業)の単位で目標とKGIがあり、それらに基づいて、部門毎にKPIがある。この関係性を理解した上で、コンサルタントは表現しきれていないKPIを上位概念である経営目標やKGIを道具にして組織の長や担当者へのインタビューを通して設計し、「サービスとしてのKPI」として定義する。正確にはこのサービスとしてのKPIは仮であり、この後実際のサービスイン後に修正していかねばならないのですが。

 

さて、概念と具体とを行き来し、KPIのすり合わせ方について論じてまいりました。

これで、左側はできた。次週、右側はどう作り込むのか。そちらについて検討を深めたいと思います。

*1:筆者の過去の経験則ですが、何らかのシステム開発運用プロジェクトが始まり、キックオフミーティングが開催されたとして、その場においては、これらは何ら決まっていません。実際、筆者はいわゆるユーザ側、ベンダ側それぞれの立場を両方経験してきていますが、これらが決まっていて始まったプロジェクトはありませんでした。正確には、何となく決まっている状態で始まった、と言っていいと思います。「現行踏襲」という便利な言葉によって。今まではそれで良かったのです。なぜなら、プロジェクトのスポンサーに相当する人たちがベンダ側、ユーザ側、さらに言えばシステムそのものも「全く同一の組織内にいた」ので。極端な言い方をすれば、KPIは「実質的に内製化」されていたのです。

考えてみてください。情シス子会社を作り経営のスリム化を図ってきた過去の時代を。情シス子会社化する前は、同じ組織同じ会社の仲間でしたね。つまり同じ組織にいて、同じ目標に向かい、同じ指標で管理されてきている。そもそもKPIがズレるわけないのです。そして、その時代にできたシステムを更改する。さらにその時代を共に過ごしてきた仲間が再び集い、予算編成権を持って新しいシステムを作る。現行踏襲でも「いい塩梅」に妥当なラインを見つけることができる。そういう構造で、「現行踏襲」を可能にしていた。しかし今はどうでしょうか?そういったいわば「同じ釜の飯を食った」人たちのナレッジや暗黙知は無くなり、労働供給が制約条件になり、一社を勤め上げるという仕組みも徐々に崩壊しつつある。さらに開発チームと運用チームが分かれていたり、そもそも運用は全く関係ない組織(海外含む)にお願いをする時代。つまり、システムやサービスを作る組織が専門化され、細分化し、参加する組織が増え、それぞれがバラバラな目標を掲げつつある。

そういった暗黙知が失われていく要素が増えていっている現在において、現行のSLAやSLOだけを追求しても表現されなかったKPIとそのKPIの背景により「このサービスにとって本来あるべきSLA」に辿り着きようがないのです。今までは、「システム単体」のKPIやSLA /SLOに特化し、同じ釜の飯を食った人たちによりそこに足りない部分、または暗黙知として言語化されないKPIが立っていた。

しかし今は「システムを含むサービス」としての成立が求められる時代にあって、言語化されてこなかったKPIを含めて評価を求められる時代になった。さらに、KPIやSLA /SLOといった「指標」を教科書的に理解し使う組織と協業する(海外の運用パートナーに委託するとか、暗黙知を共有していないベンダーと一緒にシステムを作る)という時代にあって、今までと同じ考え方でKPIを定義し、SLAやSLOを決めても「顧客が本当に欲しかった(笑)」SLAにたどり着きません。したがって、延髄反射的に「KPIを教えてください!」と突撃することそのものに意味がないのです。

KPI/SLA/SLOの関係性を考える 1/4 -導入-

こんにちは。本日は、KPI /SLA /SLOの関係性について。

これは、大変残念なことに言葉が一人歩きしまくってしまった結果、本来の関係性が断絶してしまい独り歩きを起こしてしまっている指標について、どう現実的な落とし所をつけるべきかを検討するための記事です。

ちなみに、なぜ言葉が独り歩きをしたかについての私見を述べますと…本来的にこれらの指標は、所有格を明確にしておく必要があるにもかかわらず、この所有格を外したまま喋りまくった結果、指標としてどっちつかずになり、声の大きい人(組織)にとっての指標として使われた結果、明確な定義がないままあちこちで衝突事故を起こしたものと考えています。それほどセンシティブな指標なのです、本来は。

 

 

さて、まずは原理原則から整理しましょう。KPI /SLA /SLOこれら指標の「教科書的に正しい定義」をご存知でしょうか。

  • KPI: Key Performance Indicator (重要業績評価指標)
  • SLA: Service Level Agreement (サービスレベル合意)
  • SLO: Service Level Objective (サービスレベル目標)

ですよね。では質問です。上記3つの指標、サービス提供者、サービス受益者「誰にとっての」または「誰目線」での指標であるべきでしょうか?

これは難しいですね。なぜなら、両者ともに解が存在し、両者ともに間違っていないからです。ここ大切でして、正解ではないが間違ってもいないと言っています。

 

では、筆者が正解だと思う「理想的なKPI/SLA/SLO」は何か?

大変禅問答じみており恐縮なのですが「KPI/SLA/SLOの成り立ちを合意し、その上でKPI/SLA/SLOの決め方を定義する」これに尽きると考えています。人によっては、またかよ(苦笑)と思われる方もいるかも。はい、またです。(笑)

 

本ブログでも度々言っている「(前提を)定義し、(決め方を)定義する」という事です。

今回は、「KPI/SLA/SLOの成り立ちを合意」つまり、同じ前提となる事実の積み重ねを定義し、一致させるという行為により、同じ認識に立つ。

その上で、KPI/SLA/SLOの具体的な数値を決める方法を定義する。そうすれば、後は計算で終わります。つまり、計算機(パソコン)の得意ジャンルになるわけです。

 

筆者の考える「理想的なKPI/SLA/SLO」は、下記の方程式によって成り立ちます。

図1:理想的なKPI/SLA/SLOの関係性



さて、導入という名の前置きが長くなりました。この方程式の構成要素について、合計3回に分けて、解き明かして参りたいと思います。

 

  1. 第一回:KPI/SLA/SLOの関係性を考える 1/4 -導入-←今日これ
  2. 第二回:KPI/SLA/SLOの関係性を考える 2/4-組織毎のKPIをすり合わせる-
  3. 第三回:KPI/SLA/SLOの関係性を考える 3/4-サービスとしてのSLA/SLOの決め方-
  4. 第四回:KPI/SLA/SLOの関係性を考える 4/4 –(TBD)-

どうぞ、よろしくお願いいたします。

ITSMツールで可視化する内容を何にするか。(2/2)

こんにちは。前回、ITSMツールはサービス提供状況を可視化するものである。

そして、サービス提供状況とは、サービスのQ(quality/品質)、C(Cost/コスト・ほぼ時間)、D(Deliverables/数)の3つで分解することができる。

最後にそれら3つの断面でサービス提供状況を可視化する(目的を持って定義し振り返る)ようにすることがITSMツールの要件である、というお話をしました。

 

さて、本日はその要件とはなんぞや、というお話ができればなと思います。

まず、ITSMツールとして具体的な製品名を挙げてみましょう。おそらく、人によってこれはITSMツールではないと思うものもあるはずですが、筆者の実体験も含めて記載します。(全て触ったことがあるわけではないです。いくつかは聞いただけのものもあります。)

Service Now / HPSM / Jira / Redmine / Remedy force / 千手 / Backlog / Notes(IBM)

ちらっとみて思われるでしょうか?システム運用管理ツールやプロジェクト管理ツールと呼ばれるものが混ざっています。実は、システム運用管理ツールやプロジェクト管理ツールを拡張し、「サービス提供状況の可視化」の観点で使いこなす。これがITSMツールの使い方です。

そして、このツールは、主に2つの「道具」で可視化を助けます。

具体的には、「作業制御フロー」または「(ビジネス)サービス制御フロー」と「チケット」です。正確に言えばフローそのものが重要というより、ビジネスプロセスを構成する作業制御フローやビジネスサービス制御フローになります。

そのため、図にすると下記になります。(図1:可視化の3要素とツールの関係性)

 

図1:可視化の3要素とツールの関係性

この提供状況の3要素とツールとのマトリックスの中に、要件が入ってきます。

一つの事例として、自分ならどのような要求・要件を定義するかを考えました。(図2:サービスQCDと要求・要件定義)

図2:サービスQCDと要求・要件定義

このようにQCDの観点でツールに要求・要件を決めることができます。この時、最も重要なのは、「何を達成したいか」をQCDで考え抜くということです。

そこからさらに、どのような設計を行わなければいけないか、基本設計の手前、設計方針的なものを考えてみました。(図3:サービスQCDで考える設計方針)

図3:サービスQCDで考える設計方針

サービス管理(サービスマネジメント)に何を求めるかによる部分はあるのですが、一般的な事例で考えましたので、優良可で言えば(今の大学はこういう評価しないんですかね?)、まぁ、良の中程〜可の上の間ぐらいは狙えると思います。どのような企業体であれ、最終的には定量的な指標(売上や粗利益、純利益)に集約されます。したがって、利益の成り立ちを分解するという文脈から外れない限りにおいて、このQCDベースでのツールへの要求要件定義は大きく外れないかなと。

 

毎度毎度恐縮ですが、あくまで「解」ではなく「自分の解を編み出すための処方箋」として本稿も使っていただけますと幸いです。

 

ちょっと話がそれますが、BL/PLにせよ決算にせよ、「お金をどう使ったか」に着目するのではなく、「(お金を含む)資本をどう使ったか」という観点で眺めると、「人的資本」に関して定量的な数値があまりないんだなぁと気が付かされます。最近はSDGsなどの進展もあり、「社員がどう働いているか」を定量化して決算報告に載せる企業も増えてきましたが、この場合、株を買わないとその報告に辿り着けず、投資するかしないかを選ぶという観点では、もったいないなぁと。そんなことを思います。

ITSMに限らず、定義が大事だよ、というお話。

こんにちは。ちょっと箸休め。

ITIL/ITSMに限らず、おおよそこれって大事だよなと思うことのお話。

「定義」って大事なんですよ。そんなことは誰でもわかってると思うんですが、なぜ大切かまた、どうやって共有するかを整理するために今回筆を取りました。

なお、この定義して共有するということを「可視化」と(私は)呼んでいます。

 

さて、本題。例えばですが、

体重120kg

これって健康ですか?一般的には不健康ですよね、きっと。

じゃあ、これ

体重120kg(力士)

こうなったらどう思います?なお、自分もわからないのでググってみたところ、小さめの体重とのことです。力士の方って大きいんですね。。

閑話休題

何を伝えたいかというと、数字(120kg)そのものに意味はないってことなんです。

  • 体重120kgであることとその背景を確認すること(今を定義すること)
  • 今の定義に対して「維持」「減量」「増加」いずれかの目標があること(向かう方向を定義する)

この2つを定義する事によってやっと数字に意味が生まれる。

伝えたいのはそういうことなんです。何も考えず数字を出す(定義する)ことに意味はないのです。そして、数字を出すことは可視化ではなく定義の一つ(≠全部)なんです。

以下二つのを目的とした上で、数字として定義する事に意味がある。

  • 「今」を決めるため(AsIsの状態を定義するため)
  • 「進んだ後」その道筋を理解するため(目標に対してどう進んだのかを振り返るため)

裏返すと、この2つを目的としないで数字を定義したところで意味がないのです。

AsIsの状態を定義することに結びつかない数字を出しても意味がない。そして、計測できない数字をとっても意味がない。

では、AsIsの状態を定義するための数字が何かわからない時にどうしたらいいのだろう。

その瞬間をキャプチャして、何らかの数字を置くしかないでしょうね。端的に言えば、前提を置き推定して数字にする。何と言えばいいのかな。。数字を絶対として扱わず、相対として扱うとでも言いましょうか。

数字というのは、ゼロを起点としてその量を計測するための道具です。しかしながら、私たちはその絶対的な数値を欲しているわけではなく、「今」を捉え、変化後の状態を計測したいから数字にしたいと思っているだけです。

イメージとしては以下です。(図1:数字を使った振り返り方)

図1:数字を使った振り返り方

要するに、絶対値である必要は必ずしもない。同じ取得方法で計測した結果、差が見えていればそれでいい。もちろん明確な数字である方が別のものにも使えますので(例えば契約金額とか)絶対値であればなお良いとは思いますが、それが無理なら何らかの基準/推定/前提に基づいて計測した数字で持って、一旦良しとして計測しなければ時間ばかりかかって進みません。物事を定義して進めて、振り返らないとよかったのか悪かったのかも判断できません。

 

そのため、こうやって仮でもいいから、相対でもいいから定義して、自分たちの進んできた結果を共有し、皆で振り返る。まさしく、これが可視化何です。

さて、いかがでしたでしょうか?

可視化とは定義し、共有することである。そしてこれを繰り返すことで良いサービスを作っていければいいなと思います。

ダッシュボードも、作ることが目的ではなく、共有することを目的に作られなければいけません。

そして、その共有する粒度や目的に応じて、ダッシュボードの中身は変わらないといけない。データソースは一緒、だけど見せ方が違う(決して勘違いしていけないのは、その見せ方が違ったとしても、「見えない」という状況は作ってはいけません)