1. 雨宿りとWEBの小噺.fm
  2. Season -No.149 朝活「Capabil..
2022-12-03 21:30

Season -No.149 朝活「Capability Model」をダラダラ読む回

spotify apple_podcasts youtube

はい.第149回は


Capability Model
https://www.ciopages.com/capability-model/


を読みました💁

今回も非常に抽象度が高く,戦略的な内容で正直難しかったです…!ぜひ皆さんも挑戦してみてください!


ではでは(=゚ω゚)ノ


  • capability model
  • Straw-model
  • Business Capabilities Model
  • capability map


See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:05
はい、11月29日火曜日ですね。 時刻は朝9時を回りました。昨日お届けかな?
アメリカでは、AWSのリインベントがまた今年も開催ということで、今回はしかもリアルイベントだそうですね。対面のイベントだったというところで。
僕の知り合いのエンジニアも数名アメリカに行って、そこで再開したみたいな話をしてて、すごく羨ましくなりました。僕も数年前に行きましたけどね。
まあでもこうやって、オンラインじゃなく対面のイベントが開催できたっていうのもすごくいいなって思いましたね。
また今回もすごいいろんなリリースがあったというところで、これも後ほどちょっと追っていきたいなと思います。
はい、余談でした。おはようございます。いめめめのkeethこと桑原です。では本日も朝活を始めていきたいなと思います。
本日はですね、ちょっと全然技術的な記事じゃないんですけど、僕のトゥードリストに入っていた
キャパビリティモデル。ちょっとビジネス的なお話になってしまって、こちらもちょっと技術の記事じゃないんですけど、こちらを読んでいこうと思います。
本記事は2022年、今年の8月13日に書かれた記事になりますね。 では行きましょう。キャパビリティ
ケイパビリティかな?どっちなんだろう?ケイパビリティの方が正しそうな気がするので、ケイパビリティモデルで行きましょう。はい。
では行きます。What is a Capability Model?ですけども、能力モデルまたはビジネス能力モデルというのは、ビジネス能力の統合された包括的なセットになります。
ケイパビリティモデルというのはビジネスが何を行い、何ができるかっていうのを論理的かつ流度の細かいグループ分けで分解したものになります。
ビジネス能力モデルというのは重要なビジネスアーキテクチャの成果物の一つであり、ビジネスとITの
垣橋となり、企業変革の基盤となるものになります。 ただしソフトスキルやコンピテンシーに係る
コンピテンシーモデルとかプロセスの成熟度というのを測定する能力成熟度モデルCMMなどを探しているのであれば、それらはビジネスアーキテクチャの領域にある能力モデルとは区別され異なるものになりますよということですね。
意外とそういうふうな区切りがあるんですね。結構関係するものだと思ってましたけど。ビジネスアーキテクトとエンタープライズアーキテクトというのは全体的なビジネスアーキテクチャとエンタープライズアーキテクチャの
委任事項の一部としてビジネス能力モデルというのを構築しています。 能力モデルというのはビジネスアーキテクチャの成果物の不可欠な部分であり、
ビズボック、ビジネスアーキテクチャの知識集みたいな本があるらしいです。 ビズボックの重要な構成要素でもあります。
ケーパビリティモデルというのはTOGAFというフレームワークがあるらしいですね。 ザ・オープングループアーキテクチャフレームワークの頭文字をとってTOGAFだそうです。
重要な構成要素となります。では今のが冒頭の文で続いていきましょう。
そこで疑問が湧いてきます。ビジネスケーパビリティはそもそも何でしょうかというところからですね。 ビジネスケーパビリティとはビジネスが行うことあるいは行うことができることの基本的な構成要素。
ある種のレゴブロックみたいなものですよということですね。 その核となるのは基本的な機能とフローを抽象化し名詞の形で表現したものです。
03:06
ビジネスアーキテクの中には動詞を使う方もいらっしゃいますが、私たちは文法警察官ではないのでどちらでもいいよって感じですね。
ちょっとすごいニュアンスのお話になってくる気がしていて、ちゃんと言語化しないとこれがケーパビリティ、これはケーパビリティじゃないみたいなところがしっかりした方がいいなというところがありますね。
この辺を認識した上で次に行かないといけない気がしています。 改めてみますね。ケーパビリティか否かですけどプロセスはケーパビリティではないと。これはまあ方法だったり流れを記述するもので。
バリューストリームっていうのもケーパビリティなさそうですね。 これはプロセスではなくステークホルダーやアクティビティが関与するエンドツーエンドのフローになりますと。
システムまたは技術ですね。っていうのはケーパビリティを組織がするために使うけどケーパビリティではないと。
最後組織図もケーパビリティモデルではないよってところです。 それを踏まえた上で続いていきましょう。
続いてケーパビリティモデルを分解するケーパビリティモデルの例だそうですね。 でいきますが能力モデルって翻訳されたりケーパビリティモデルそのままだったりするから
ごちゃごちゃしますね。ケーパビリティモデルまたはビジネス能力マップとかいわゆる能力モデル的なものですね。
というのはミーシーモデル。ミーシーはミーシーです。いつも通りなんですね。に準拠した構造的に健全で内部的に論理的な能力群でありますと。
すでに日本語が難しいな。構造的に健全かつ内部的にも論理的な能力群でありますと。
ちゃんと説明がされているし、過不足なくというところですね。 いくつかレベル分けがされていますね。
レベル1はバリューチェーン、レベル2がセールス、レベル3がCRM、レベル4がクライアントセグメンテーション、レベル5がオポーチュニティベースというところですね。
というベースでそれぞれのケーパビリティモデルというのがバーッと語られている感じです。 ちょっとこれは本記事を多分皆さんの方でも読んでいただく方がいいかもしれないです。
画像がぺって貼られていて、僕はちょっとわかりやすく見えているんですけど、 これは多分見ないとわからないかもしれないですね。
例えば多くの基本能力を組み合わせて、その販売だったりとか販売管理能力というのを実現することができます。
図に示すように販売というのはその7つのレベル2の能力の集合体になります。 レベル2がセールスというところですね。
その中にその販売という能力があるので、そこに含まれますよということですね。 それはいくつかの能力さらに分解化ができて、
販売管理とか販売計画および予測だったり、テリトリー管理、リードとオポーチュニティ管理だったり、 顧客関係管理、関係の関係ですね。
見積もり契約交渉だったり、受注管理だったり価格設定だったり、 この辺がそのケーパブリティモデルのそのレベルにセールスというところの話でした。
などなどこんな風な感じの切り分けができるそうです。 では続いて続いて、これすごいケーパブリティモデルちょっと難しいな。
ちゃんとなんか別の本とかちゃんと使い方みたいな記事が欲しくなってきましたね。 ではなぜケーパブリティモデルのフレームワークっていうのはそのエンターブライズツール
キットのスイスアーミーナイフなんでしょうか。 なかなか例えがまた面白いですね。スイスアーミーナイフですか。
06:05
よく使われる軍事的なナイフですね。 ケーパブリティベースの見方というのは、いわゆる論理的直感的というのが一つで、二つ目に安定した
というものですね。そして非冗長だけど広範囲。 あとは機能モデルよりもより豊富というところですね。
を提供するものがケーパブリティベースの見方だと言っています。 また
ビジネスについて私たちがいかに考えるかというのを組織してくださいねというところとか、 ビジネス戦略及びパフォーマンスを浸透して追跡する能力だったりとか
分断横断的なコミュニケーション。ビジネスとITみたいなところですね。 あったりとか、要件を収集して進化のロードマップの開発しましょうとか
などのところを提供してくれるそうですね。 例えばCRMですね。カスタマーリレーションシップマネジメント
というCRM能力モデルというのを構成するものを定義したい場合は、先ほどの図を見つつ CRMというのは以下の能力で構成されるというのを理解することができます。
例えばCRMというのは顧客セグメンテーションだったり、顧客の連絡先管理だったり、 インタラクション管理、利益管理、顧客分析、活動計画及び会議管理などなどというのが
CRMの能力だというところですね。 したがってもし企業が自社のCRM能力というのを評価し、CRM能力をリプレイするか再プラットフォーム
がするというのを決定したいのであれば、 CRM能力の詳細な構成が役に立つでしょうと。特に
現状を評価する、将来の能力を想定する、ギャップ分析を行う、 変換ロードマップを定義する、競合するCRMプラットフォームのベンダー分析を行うなどなど
というところが重要になってくるようということですね。 続いていきましょう。ケーパーメリティモデルをどのように作るかというところが次のセクションですね。
私たちはケーパーメリティモデルを構築するためには2つの有効なアプローチがあるというふうに考えています。
まずが1つ目です。2つのうちの1つ目はゼロからケーパーメリティモデルを作成しましょうと。 専門からなる部門横断的なチームというのを集めてケーパーメリティモデルというのを定義しますと。
一般にそのケーパーメリティモデルの作成チームというのは、ビジネスアーキテクト、エンタープライズアーキテクト、プロセスオーナー、プロダクトオーナー、人事財務会計、
マーケティング販売、オペレーションなどなどの分野の機能スペシャリストからも構成されますと。
どちらかというとビジネスサイドの人たちとかバックオフィスの人たちが結構多く集められるような印象ですね。これを見るか。
というのを集めてゼロから横断的なチームをまず作ると。 一連の進行型ワークショップ及び会議室というのを数えきれないほどの時間、大量のカフェイン、これはコーヒーのことね。
無数の議論を通じてチームというのはそのケーパビリティモデルをまず作成しますと。 このプロセスには数ヶ月、大企業では1年半から2年程度かかると言われています。
すげーな。これもはや経営計画に近い話じゃないですかね。 そのケーパビリティモデルをゼロから作成することのやはり利点というのは
09:02
オーダーメイドですね。自家製でありプロセスがカタルシスをもたらすことということですね。 これは結構大きいですね。プロセスがカタルシスを持つというのはなかなか大きいと思います。
何度も合意形成を行うことでビジネス能力が企業全体の実際の使用例で使用される可能性があるということですね。
ご推察の通り、私たちはこのアプローチのファンではありませんし、時間とかエネルギー、労力、摩擦が結果になっていないということを目の当たりにしています。
結果は遅いという形ですね。もちろんしっかり考えてみんなに浸透するようなモデルが作られればそれはいいですけど、
企業によっては1年半から2年ぐらいかかると言われたら、2年もかかったら人も変わるし、下手したら体制とか社内制度が変わったりする可能性もあったりするので、
これはさすがにちょっと遅いなというので、まあ受けられないなって感じですね。 やるとしたら本当にまだまだ少数の会社とか小さいところでちゃんとドラスティックに問題、
組織を見直したいときに使うのが良さそうな気がしました。 もう一個の方法ですね。もう一個の方法はストローモデルまたはサンプル参照
ケーパブリティモデルというものに基づくアプローチだそうですね。 ストローモデル、また新しい名前が出てきましたね。
読んでいきますか。ビジネス能力モデルのサンプル、テンプルサンプレート、サンプルテンプレートっていうのは時間、エネルギーおよびコストを
削減することによって、その能力マッピング作業というのを加速するのに役立ちます。 ciopages.com というページがあって、そこでは機能分野や様々な業界向けの
本格的なビジネス能力フレームワークっていうのを販売しているため、なんか偏見があるかもしれませんが、私たちはそのビジネス能力モデルとかテンプレートのアプローチのファンであり、保持・改良を強化しすぐに実行できるようにしています。
サンプルのストローモデル中心のアプローチでは、労力というのを最小限に抑え、完成までの時間を短縮して摩擦を減らし、チーム80%の
砂漠なことだったり、あまり重要ではない周辺能力にとらわれることなく、企業にとって重要であろう20%のことに集中することができるようになります。
その代わりにビジネスケーパビリティマッピングのパラダイムに詳しい専門家、
ビジネスアーキテクチャだったりとか、エンタープライズアーキテクチャだったりとか、ビジネスの IT リーダー数名からのグループなどなどとかですね。
が数名集まり、ビジネスケーパビリティマップのドラフトを作成する必要もあります。
目の前にあるものを見ることで、他のチームメンバーも効果的に参加し、企業が必要とするもののケーパビリティモデルを進化させることに貢献することができますと。
そのケーパビリティモデルの検証セッションというのは、より生産的で楽しいものになるでしょうと。
企業の文脈で楽しいという言葉は適切かはちょっと難しいですけどということですね。
モデルの流動を吟味したくなりますけども、ギャザーだったりフォレスターのサンプル能力モデルというのも公開されてますので、興味ある人は見てみてくださいというところでした。
本記事の中からリンクが貼られてますので、興味ある人は後ほど追ってみてくださいというところです。
これは明らかに後者のやり方の方が絶対いいなと思いますね。
ストローモデルについて結局語られてなかったので、ストローモデルってなんだろうっていうのはちょっとありますけど、
12:00
ちょっとずつ吸っていくみたいなところだと思いますね。小さく小さくやるんだろうなみたいな感じはしました。
では続いて、ケーパビリティモデルを構築するためには結局何から始めりゃいいのというところです。
もちろんベンダーから購入したものであれ、小人数の専門家ブルーグループが作成した内部ドラフトモデルであれ、
サンプルまたは参照用のケーパビリティモデルから始めることに興味がなく、代わりにゼロから構築することを主張する場合、ここにいくつかの開始ポイントがありますよと。
他の会社が作ったものとか、その専門家ブルーグループが作ったものとかですかね、っていうのを購入することもできると。
ケーパビリティモデルって販売されてるんですね、モデルそのもの。なかなかそれはそれで面白いですね。
一応なんかこの記事内にもそのサンプルのモデルをプロダクトとして販売しているものもありますね。
エンタープライズビジネスキャパビリティモデルズとかがあって、だいたい2499ドルから、ものによっては5999ドルで売られています。
他には、エマージングデジタルテクノロジーズアセスメントみたいなモデルですね。
で、こちらも25ドルから75ドル。
で、最後、ファイナンス&アカウンティングビジネスキャパビリティモデルっていうのがあって、こちらは699ドルから1999ドルですね。
などなどっていうところで、一応販売もされてるらしいですね、ケーパビリティモデルっていうのは。
ビジネスモデルそのものをプロダクトとして販売するっていうのは、パッケージ化してるっていうのは結構面白いなと思いましたね。
でもそれぐらい必要なもので重要だったりするんだろうなってところですね。
余談です。
では、ゼロから構築するための開始ポイントみたいなところに行きますが、バリューチェーンからまず始めましょうと言ってます。
バリューチェーンはマイケル・ポーターで有名な古典的なフレームワークであり、トップマネジメントは通常このフレームワークをよく理解してますと。
そのために企業のバリューチェーンから始めると素晴らしい出発点になります。
例えばあなたが製薬会社であれば、バリューチェーンと必要な能力は次のようなものになるでしょうというふうに言われています。
次のようなものですけど、ケーパーベリティー層部はあんちゃらかんちゃらですね。
製薬会社のケーパーベリティーだと。
主な能力の一例ですけども、1、2、3、4、6点ありますね。
順序に行きます。
研究と創薬が1つ目、2つ目に医薬品の開発、3つ目が知見と医薬事、承認ですね。
4つ目に製造、5つ目に流通ですね。
最後6個目が販売とマーケティング。
この辺が製薬会社のケーパーベリティーですと。
そしてバリューチェーンを構成する多くのサポート能力が必要に存在することになりますと。
そしてバリューチェーンレベルの能力を流度の細かいエンティティに分解して、全体的に統合されたビジネス能力モデルというのをマップを作りましょうというふうに言っています。
ではどこまで下げるか。
ビジネスケーパーベリティモデルの流度というところですね。
私たちはビジネス能力をレゴブロックまたは原子ブロックみたいなものと考えるのであれば、
その原則の論理的解釈というのは、より深い流度のレベルまで分解することだというふうに考えています。
レベル1に留まるケーパーベリティモデルというのは、
That's what we doを見事にまとめたウォールアートにすぎないと考えています。
15:02
レベル1はそれぐらいの流度なものです。
もしモデルがレベル1、レベル2の能力で構成されているのであれば、
それは戦略的な絵であり、興味深い会話をするための経営者レベルの成果アプリであると私たちは考えています。
レベル3、4、5、必要に応じてまでのケーパーベリティマップには、
業務の最適化、変革のロードマップ作成、およびITの実現において非常に価値のある実行の詳細が含まれています。
経営者レベルのサポートを得るためにレベル1、2から始めることも一応できはしますが、
ビジネスアーキテクチャチームにはケーパーベリティマップの付加価値を高めるために、
論理的な流度のレベルまで分解して進めることを強くお勧めします。
やっぱり最低でもレベル2ぐらいまでは落とし込んでから経営者のところに持っていくのがまずはいいんだろうなということですね。
3、4、5は本当に必要に応じてその流度のものを持ってきてくださいというところですけど、
一応準備をしていくのがいいのかなと思いますね。
発表自体はレベル2ぐらいの流度の話でいいと思いますけど、
聞かれたり突っ込まれた時に答えられるように3、4ぐらいまでは考えておいてもいいかもなという感じですね。
では続いて、ケーパーベリティモデルは一つで終わりなのかというところですけども、
ビジネス能力っていうのは、より安定的かつ長期的である一方、進化とか変容、または新たに出現するものでもあります。
したがってケーパーベリティモデルというのは決して終わっていない。
それは絶えず変わり、展開するものになります。
ケーパーベリティそのものは変わらなくても、企業が育みたい成熟度だったり、ケーパーベリティの実現方法でやっぱり変化をします。
したがってビジネスアーキテクトやその他のビジネス能力マップの管理者は、
成果物を更新し、アップグレードするよう継続的に努力する必要があります。
また、戦略的重要性、また成熟度、および望ましい目標状態について能力を定期的に再評価することも重要です。
ケーパーベリティモデルの作成と管理にはどのようなツールを使用すべきでしょうかというところですけど、
ケーパーベリティモデルは動的で生きた存在であるため、ケーパーベリティを作成管理するための静的なツールというのは適切ではない。
したがって汎用のオフィス生産製ソフトウェアではうまくいきません。
利用可能な多くのケーパーベリティモデリングソフトウェアツールというのがあるんですけど、それのいずれかを使用することが望ましいでしょう。
オフィスで管理するのは厳しい、エクセルは無理だよと言ってますね。
テーブラーやDOMOなどのデータ可視化ツールを使用するのも効果的です。
また高度なデータ操作には、エクセル、エグゼプティ向けのプレゼンテーションにはパワーポイントを使用するのも良いでしょう。
しかし日々の能力管理は専用のソフトウェアで行う必要があります。
プレゼンにはそういうオフィスは使ってもいいけどということですね。
ちょっと時間をオーバーしたんですけど、あともうちょっとなので走り切っちゃいたいと思いますね。
ビジネスケーパーベリティモデルを作成した後、ケーパーベリティマップを作成した後の次のステップは何でしょうかということですね。
守備一貫した包括的なビジネス能力モデルが出来上がったら、次のステップとは以下の通りです。
必要なケーパーベリティの属性をまずまとめましょうと。
ケーパーベリティの定義、ケーパーベリティの目標及び目的、現状のケーパーベリティ評価というところですね。
続いて望ましい目標状態に到達するためのケーパーベリティの必要性のところですけど、
18:03
まずやっぱりメトリクスを取っていきましょうとか。
あとはビュートモデルの作成だったりとか、システムフットプリントに対するケーパーベリティだったりとか、
ケーパーベリティからサービスフットプリント、SOAサービス、またはマイクロサービスなどなどですね。
他、能力からロケーションへのマッピング、能力からロールマッピング、そしてデータマッピングへの能力、
IT製品モデルへのマッピング、その他企業のニーズに応じたもの、バックログとか将来のニーズを能力に合体させるなどだとか、
あとは機能レベル、ビジネスユニットレベル、企業レベルの変革ロードマップを作成するために能力を利用しましょうとか、
ベンダーの機能及びフィーチャーマッピングのためにケーパーベリティモデルを活用する、
ラスト、SOAサービスとかマイクロサービスのモジュール性だったり流動にケーパーベリティをドライバーとして影響させるというところです。
最後、この辺がリストとして述べられて、この記事は終了となりました。
はい、すげー蜘蛛を掴んだような記事で、すいません。
読んで、僕も読んでて、ふーんっていうか、理解できなかったっていうのが正直な感想で、これ大変に申し訳なかったですね。
今朝の朝々、かなりグダグダしてしまいましたが、途中にありましたケーパーベリティモデルのサンプルとしてレベル1からレベル5っていうのがあったんですけど、
ここが結構肝になるんだろうなっていうのがすくずく思いました。
バリューチェーンとセールスですね。
ここまでで既に経営者のレベルまで話ができると。
あとCRMとかクライアントセグメンテーションとか、オポーチュニティベースというレベル5のところはかなり細かいお話なので、
ここまでの話を経営層にするかというとそんなにないと思いますね。
あとCRMも、CRMがそもそも求められるケースがどれくらいあるのかっていうのがあったりするし、ビジネスのモデルによっては全然話が変わるのであるんですけど、
ビジネスって時点で絶対顧客がいる話ではあるので、代償はあれど影響はあるんだろうなって思いますけど、っていうところですかね。
なのでこのモデル、その記事の中にあるこの5つのレベルの画像は見ておいていいと思いますし、これはインストールしてもいいなと思いました。
またこれをベースに、それぞれの自分たちのビジネスモデルというところにどういうケーパビリティがあって、それに対してどういう体制を組んでいったりとかっていうのを考える一つの指標に使うのは全然いいなというふうに思いましたので、
これはこれでビジネスマンとして一つ、頭の片隅に入れておいても損はないなというふうに思いましたね。
ただこれをちゃんと本気で考えて、会社レベルでやるとなると、もうすごくエネルギーと時間、コストがかかるっていうのもすごく痛感しましたし、
作って終わりではなくそれを運用して初めてこのモデルというのは機能するというところですので、
この辺はやっぱりそうですよね。作って満足しちゃダメだよなってところだし、目的と手段が入れ替わっちゃダメだなっていう、ここは結構注意点だったりもしました。
では、ちょっと長くなりましたけど、ケースの長さがこちらで以上にしたいと思います。この記事また皆さんの方でも読んでみてください。
内容自体はビジネス的なお話だったので、あまり興味ない方もいらっしゃると思いますけど、参考になるかなと思います。
では、明日以降ですね、やっぱり冒頭で述べました通り、AWSのリーグイベントがあったので、それの更新記事、たぶんくらめどさんがいろいろ書いてるだろうというのを信じて、その辺をちょっと追っていこうかなと思います。
21:07
いくつか読んでみたいやつもあったり、すでに僕もいくつかリリース見てよ、これいいじゃんみたいなのが見つかったので、その辺を明日は、さすがやっぱりリーグイベント中なので、ちょっと追っていこうかなと思っておりますので、興味があれば参加してみてください。
では、今日火曜日、あと11月もあと2日ですね、頑張っていけたらなと思います。それでは終了したいと思います。お疲れ様でした。
21:30

コメント

スクロール