「理念」と「実存」とのあいだ
今回はArchiMateのストラテジー・レイヤーにある4つの要素をご紹介します。モチベーション要素は「可変の未来」、構造や振る舞い要素は「不変の過去」の表現ですが、ストラテジー・レイヤーの要素は、「不変の過去の抽象化」「可変の未来の具体化」で、「理念と実存」「未来と過去」を繋ぐ構造を描くのに使います。
ストラテジー・レイヤーは「ビジネスモデル」
ストラテジー・レイヤーの主な要素である「バリュー・ストリーム」、「ケイパビリティ」そして「リソース」の3つで、組織のビジネスモデルを、もっともプリミティブなカタチで表現できます。
ビジネスモデルというと、新規事業で描くものをついイメージしがちですが、すでに存在する事業にも、そのエンタープライズ・アーキテクチャの構成要素として当然存在します。ArchiMateではストラテジー・レイヤーの要素を「ビジネスモデル」、ビジネス・レイヤーの要素を「オペレーション・モデル」の表現に、それぞれ用いることが出来ます。
オペレーション・モデルが「部長さんレベル」の粒度とすれば、「ビジネスモデル」はさしずめ「事業本部長」や「執行役員」レベルの粒度感です。
継続事業において、このレベルでのビジネスモデルの表現は、グループ連結レベルのアーキテクチャを描く上でとても役に立ちます。グループ連結のオペレーションを「部長さんレベル」で表現しようとすると、要素が多すぎて読解不能になりますが「管掌役員レベル」なら、どの事業セグメント、すなわちバリュー・ストリームが、グループ内のどの組織のケイパビリティやリソースに依存しているか、をシンプルに表現できます。
バリューストリームとケイパビリティ、そしてリソースにはそれぞれ固有のライフサイクルがあって、それらの間には常にギャップが存在します。ITのケイパビリティやリソースについて、これらのギャップことが、いわゆる「ビジネスとITとの整合 (alignment) 」であり、インハウスITの主たる役割のひとつ、ということになります。
それでは、ストラテジー・レイヤーの各要素について、実際の用例を考えていきましょう。
バリュー・ストリーム
これは既に記したように、業績開示上の「事業セグメント」扱いにするのが良いでしょう。管掌役員レベルと事業本部長レベルの2階層くらいにしておくと、グループ内販取引の表現や、よくある開示セグメントの組み換えのときなどに便利です。
各事業会社そのものは「アクター」で表現します。事業会社或いはPEと、開示セグメントとはn対nの関係にあることも多いでしょう。
上位のバリュー・ストリームの名称には開示セグメントのそれがそのまま使えます。下位のバリュー・ストリームの名前は「やっていることがわかる」ようなものを付けるのが良いでしょう。
ケイパビリティ
これはビジネス・ファンクションの上位概念です。ビジネス・ファンクションは「部長さんレベル」の「管理機能 (マネージメント・ファンクション)」だったので、ケイパビリティは事業本部長や執行役員レベルの「執行機能 (エグゼクティブ・ファンクション)」の表現を使うのが早道です。
先に「リソース」との違いを述べておくと、ケイパビリティは組織に固有で、外から買ったり借りたり出来ないものです。一方、ケイパビリティに使うリソースは外から持ってくることが出来ます。これがアウトソースです。
これもバリューストリーム同様、2階層くらいで描くと良いでしょう。例えば、管掌役員レベルの「製造」ケイパビリティの下に各工場レベルの「何々の製造」ケイパビリティがぶら下がるイメージです。「ケイパビリティ・マッピング」という手法も有りますが、あまり細かく書くと抽象度的にファンクションとの区別がつかなくなるので注意が必要です。
また、人事・経理・ITのスタッフ部門には独立したバリューストリームはありませんが、専門的な職能としてケイパビリティを保持しています。これらのケイパビリティは、各バリューストリームによって「消費」されます。
ケイパビリティはオペレーショナルなものとストラテジックなものに大別されます。「製造」はオペレーショナルなケイパビリティですが、「商品開発」はストラテジックなものです。感覚的に表現すれば、”Do things right”と"Do the right thing"の違いです。
スタッフ部門も、人事ならペイロールはオペレーショナルな、タレマネはストラテジックなケイパビリティです。ITならいわゆるDevOpsのDevがストラテジック、Opsがオペレーショナルなケイパビリティとなるでしょう。
自分の組織を継続事業足らしめているのはどんなケイパビリティか、どれがオペレーショナルで、どれがストラテジックか、などを整理するのは重要です。なぜならこれらがイノベーションやガバナンスの戦略方針として、モチベーション・レイヤに繋がっていくからです。難しいでしょうが最初から完全を目指す必要はありません。まずは始めることです。
リソース
割り当てられるケイパビリティによって、リソースもオペレーショナルなもの、ストラテジックなものに分かれます。
生産や販売の拠点や設備は典型的なオペレーショナル・リソースです。製品開発拠点はストラテジックですね。データサイエンティストとかの専門知識も、ストラテジック・リソースです。
ただし「データ」、いわゆる情報資源は、どちらのケイパビリティにも割り当てられます。この、正にいま作らんとしているエンタープライズ・アーキテクチャのモデルも、データとしてオペレーショナルにもストラテジックにも使えるでしょう。たとえばオペレーショナル・ケイパビリティなら「導入教育 (いわゆるオンボーディング)」、ストラテジックならまさに「エンタープライズ・アーキテクチャ管理 (マネージメント)」です。
先述のごとく、オペレーショナル・リソースはしばしばアウトソースの対象になります。「勘定系システム環境」リソースは、ケイパビリティへの割り当てはそのまま、組織内のオンプレからクラウドに出て行ったりしますね。
逆の見方をすれば、外部調達できない (カネで買えない・市場価格が存在しない) リソースがストラテジック・リソースであるとも言えるでしょう。オペレーショナル・リソースは代替可能な、コモディティとして市場価格で取引可能なリソースですね。カスタマと自社とのインタラクションの記録なんかは、正にストラテジック・リソースそのものでしょう。
能動構造要素はコストである、と以前書きましたが、リソースはまさにそのコストの集大成、ということになります。リソースの総額は幾らなのか、どちらに幾らずつ掛かっているのかというイメージを常に持つことで、リソースのマス (質量) を感じられるようになるでしょう。
また、ArchiMateの要素はデータで、要素にはいろいろなプロパティ (属性) を持たせることが出来ます。つまり、能動構造要素のコストをロールアップして、リソースコストの合計を出したりすることも不可能ではありません。そうするとリソースコストのリターン比較とか、経時的な推移とか、いろいろな分析が出来るようにもなります。タダの「絵」だとこうはいきませんね。すぐに実現しなくても、将来の可能性は大事です。
コース・オブ・アクション
前回、モチベーション要素の「アウトカム」は、中計に載せる連結レベルの施策、というお話をしましたが、コース・オブ・アクションは、これの事業セグメント別のブレークダウンです。アウトカムがCxOレベルの、コース・オブ・アクションは、事業本部長レベルの施策、と考えれば良いでしょう。
つまりこれはビジネスモデル上の変化です。ケイパビリティを追加する、強化する、そのためのリソースを調達する、そういった「打ち手」を表すものです。ケイパビリティを減らす、とか、リソースを捨てるとかいった、後ろ向きの打ち手というのももちろんあります。
ということは、このあたりのモデルをちゃんと描けば、プロジェクト立ち上げに使えますね。ビジネスモデルのどの範囲のどんな変更で、どの組織がインボルブされる、どの上位方針と関連してどんな要求や制約があるといったことを、これを使って済々粛々と説明することができます。
この変化を実現するのが「導入と移行」レイヤーの各要素、ということになります。これは次回ご紹介することにしましょう。
BCGマトリクスにしてみる
最後に、バリューストリームやケイパビリティをBCGマトリクスに関連付けてみた絵をご紹介します。ケイパビリティの名前はここでは独断による分類を書いています。
「負け犬」のケイパビリティはそもそも無いでしょうから、中身には代わりにリソースの類型を入れています。「技術的負債」には世間では大きく2つの異なる意味、即ちアジャイル開発での「時間的制約に合わせて意図的に取得するもの」と、日本の伝統的大企業によくある、サンセットし損ね (し忘れ) の勘定系などの「結果的に残った厄介なもの」がありますが、ここでは後者を指しています。「埋没費用」は、COBOLのストコンで時間稼ぎ、などがそれに当たるでしょう。いずれにせよ、あくまでご参考です。
こうやってみると、前回のモチベーション要素での「要求」と「制約」で、縦横を置き換える、という見方も出来るでしょう。縦が制約的支出、横が要求的支出です。「金のなる木」を守るのに要求的支出を掛ける、「疑問符」の大穴狙いで制約的支出を掛ける、花形は要求的、制約的両方の支出を掛ける必要がある、ということになります。
「脱縦割り」の見える化
今回ご紹介したストラテジー要素は、他のレイヤーより先に取り組んだ方が良いかも知れません。モデルの要素の個数は大したことないでしょうが、夫々の要素は重要で、そのレベルの概念を如何に組織内の共通認識として抽象化するかは、ちょっと大変そうですが、見返りも大きそうなチャレンジです。
ITやビジネスなどの各専門分野で、いわゆる身内コトバで抽象化・言語化するのは比較的たやすいことでしょう。しかしこのレベルだと身内コトバというわけにもいかず、他の部門にも通じる表現でなければなりません。何なら「自分が気に入るか」より「周りがどう捉えるか」の方がむしろ大事です。
しかしその苦労は、例えばHRが各部門のケイパビリティをよく理解し、本来のニーズに合った人財をアサインしてもらえる、といったカタチで報われるでしょう。
かつてのorganic growthメインの時代では、成長は分け合うもので、それにはサイロ縦割りはぴったりでした。その時代は終わって久しく、成長は自分で見つけて仕留めるものですが、サイロ縦割りでは身動きも取れませんね。
現状ベースのビジネスモデルを描くと、恐らく縦割りっぽくなるでしょうが、それはそれで出発点をセットした、という意義があります。そこからケイパビリティを足したり組み合わせしたりして行けば、とかく掛け声倒れに終わりがちな「脱縦割り」の実際の姿が現れるのではないでしょうか。
--------------
次回は「導入と移行」レイヤーの各要素をご紹介します。WFでもアジャイルでも使える、プロジェクトのArchiMateによる表現です。おたのしみに。