mark-wada blog

前回、目下の研究課題として、ビジネスモデルからビジネスプロセス、オペレーションという落とし込みをしてみようという話をした。そこで、ここから、「ビジネスモデルを実装する」と題して連載していこうと思う。

最初は、ビジネスモデルというのはそもそも何なのだろうかということである。その昔、ビジネスモデル特許というのがもてはやされて、その特許をとると大金持ちになるなんてことが言われ、奇妙な特許が成立していたりした。

ここでは、もっと素直に事業のやりかただとか収益を生む仕組みだとかいったものを考える。その定義としてわかりやすい慶応大学の国領二郎教授のものをみていきましょう。

Wikipediaによれば、ビジネスモデルを、経済活動において、「四つの課題に対するビジネスの設計思想」と定義していて、

　１．誰に、どんな価値を提供するか。
　２．その価値をどのように提供するか。
　３．提供するにあたって必要な経営資源をいかなる誘因のもとに集めるか。
　４．提供した価値に対してどのような収益モデルで対価を得るか。
ということになる。

も少し、噛み砕いてみると、１の誰にどんな価値をというのが肝ですね。この意味は字句どおりですが、これがないビジネスモデルも時にはみかけることもあります。例えば、儲かれば何でもするといったものです。これとてビジネスモデルと言えないことはないのですが、たぶん長続きしない泡沫モデルでしょう。

２のどのように価値を提供するのかというのはいろいろありそうです。顧客にどう届けるのか、パートナとどういったコミュニケーションを行うのかとか、どういう流通経路をとるのかとかいったことがあります。以前、コンテンツ、コンテナ、コンベアという話をしたことがありますが、この3つの要素でサービスが成立していて、その重要性が年々後ろの方、すなわち、コンテンツからコンテナ、コンベアーの方に移っています。ここのことです。ただいいものを作っただけではビジネスにはなりにくくなっています。

３の経営資源は、どんな経営資源をどのように調達して、それをどう組み合わせるのかといったことです。そして、忘れてはいけないのが、４のちゃんとした収益モデルが確保されているのかということです。簡単に言えば、どういう価格体系で価値を提供するかである。ビジネスは慈善事業ではありませんから、いくらいい理念をかかげても適正な利潤をあげないといけません。

こうしてみていくと、価値とその価値を生み出す要素に対して、“誰”に“どんな、いかなる、どのような”ものを、“どのように”提供するのかをデザインすることだとわかると思います。すなわち、顧客を特定し、価値を創造し、経営資源を組み合わせて、パートナと意思疎通を図り、最適な流通経路を選定し、適正な価格体系を決めることです。

このそれぞれの要素について、自社のもつ強みだとか、経営資源だとかを鑑み定義していくことになります。次回は、一番重要な価値とはどういうことなのかを議論します。
　　

さて、ビジネスモデルを考える第一歩が、“価値”ということだろうと思う。ただ、重要なのは、それだけ単独で考えるべきものでもないということです。例えば、お客さんを先に決めることもあるかもしれません。何かに困っている人が多くいるので、その人たちを助けるためにビジネスモデルを考えるということもあるかもしれません。

また、自分たちの経営資源が遊んでいるとか、ある事業で成功した優れた経営資源があるからそれを転用しようとかいったアプローチもあるかもしれません。しかし、それらはきっかけとしてはあるかもしれませんが、結局はどんな価値を提供するのかの定義に集約されていくような気がします。

さて、“価値”とは一体何でしょうか。ビジネスの世界で、“価値がある”とは何をもってそう言っているのでしょうか。儲かった結果として、その価値はこんなことであったという後付けもありうるのだろうか。そうしたたまたまうまくいった式はほとんどないと思う。どんなものでも、あえて意識はしないこともあるかもしれないが、ある価値を訴求しているだろう。

価値とは、「差であり、違いである」と考えています。競争相手との差が価値を高める、いままでと違うもので価値を生み出すといったことです。他社と全く同じものを提供することでも顧客が喜べば価値を提供することであるという理屈はあるかもしれませんが、それは結局、収益モデル的に問題があるように思います。

この「差であり、違いである」をもう少し具体的な言い方をすると、比較優位性、特異性、新規性ではないかと思います。比較優位性というのは、大小、多少、早さ、重さといったものの比較の上で優位に立つことである。世界最小の何とか、大量の処理ができる、最速が出せる、軽量なんとかといった具合である。こうしたところに価値をみつけることがあるでしょう。

特異性は、従来からあるが、その概念とまるで違った形のものとか、全然違う使い方を提案するとかいったものである。ある限定的な顧客にのみのサービスといったこともあるかもしれない。昨日のテレビで阪神タイガースファン限定の携帯というのがあったがそれである。従来と異なる形、型式、方式、対象、手順などによる差別化である。

新規性は字のとおり今までにないものを創造することである。世の中にないものを初めて市場に投入するというようなことで、これは何もモノとして新しいというだけではなく、新しいサービスだとかスタイルだとか、それこそ業務プロセスだって新規性という価値がある。

ですから、“どんな価値”を提供するのかという場合、それは比較優位にあるものであるのか、異なるモノやコトであるのか、今までにない新しいものであるのかどうか、そうした切り口でどれかにあてはまれば価値があると言えるのです。

前回、価値とはどんなものであるかを議論しましたが、今回はその価値を提供する相手はだれなのかの話になります。ただし、まず価値ができてそれをどこに提供するのかというふうに考えるわけですが、そうした順番だけではなく、価値を提供する相手によってその価値も変わってくる場合もあるので両方をにらみながら行ったり来たりして決めていくのが実際的ではないでしょうか。

このことはマーケティングのセグメンテーションになります。だれにということはどういう市場に商品を投入するのかということに他ならないからです。以前に紹介した「マーケティングを学ぶ」（石井淳蔵著　ちくま新書）の事例を参考にして考えてみましょう。

マーケティングの基本はSTPです。すなわち、Segmentation、Targeting、Positioningということで、このうちPositioningは経営資源に関係するようなことなので、Segmentation、Targetingが“誰に”に関係します。市場を細分化して、ターゲット顧客をどこに置くかです。

この本に出てくる事例では、青芳製作所という燕・三条にあるスプーンやフォークの金属食器メーカーが、中国メーカーに市場を奪われると、障害者・高齢者という小さい市場をターゲットにおいて、障害者用スプーンを開発して販売し成功した例があります。

他にも、元々運送業者だった寺田運輸という会社が、運送市場を細分化し、ターゲットを引越ユーザに定め、アート引越センターとしてその業界で生き残った例や、安定した客層であるビジネス旅客に絞り、“正確な時間”予定通りに希望地に到着するという価値を提供して業績を伸ばしたスカンジナビア航空などの例があります。

結局、「誰に向けて、どういう価値を、どういうオペレーションあるいは技術で提供するか」という顧客層－価値－オペレーション（技術）の3要素の首尾一貫した統合が大事なのである。

このように市場を細分化してターゲット顧客を特定して行くわけですが、それがシステム的にどういう関連があるのかとふと考えてしまうでしょう。おそらく従来の業務システムはこうした顧客接点でのサービス、あるいは顧客獲得、アクセスのしやすさといったことに関心がなかったのではないかと思うのです。

しかし、これからのシステム、少なくともビジネスモデルを実装しようと意図したからには、ここは外すわけにはいかない、というよりこれからの時代では非常に重要な領域であるはずです。ですから、お客さんの特性、例えば上の例では、食器を買いたい障害者、引越をしたい独身女性、会議に遅れたくないビジネスマンにはどういった仕組みや仕掛けが要るのかを考量しなくてはいけないのです。

その重要なコンポーネントのひとつのはマンマシンインターフェースとかユーザインターフェースだと思いますです。これからは、こうした使い勝手のよいサービスをどう届けるかが大事になってきます。そうなると作り手側では何が必要かというとユーザビリティデザイン力が問われてくるのではないかと思っています。
　

ビジネスモデルを実行するためには、ターゲット顧客に価値を提供するのを支える経営資源がなくては実現できません。いくらすばらしいビジネスモデルを考えついても人や設備がなくてはできません。ですから、制約条件として経営資源があるわけです。逆に言えば、潤沢で優れた経営資源があれば、制約とはならずに、ビジネスの成功を後押ししてくれるのです。

それでは経営資源とはいったいどんなものがあるのでしょうか。よく言われるのが、ヒト、モノ、カネ、情報でしょう。それはそれでいいのですが、これだと漠然としているのでもう少し具体的に掘り下げてみましょう。

ヒトは、人材および組織といったものでしょうが、実は目に見えない無形の資源が大事になります。このことは、ヒトに限らず、モノやカネでも同じように形のあるものと無形のものがあります。ですからその両方をみていく必要があります。ヒトでは会社へのロイヤリティだとか人脈とか文化・風土なんかも含まれてきます。

よくトヨタの強さはカンバン方式に代表される生産システムにあるとよく言われますがそうでしょうか。そうではなく、部品を供給する系列会社がみな忠誠心が強いことやトヨタイズムを忠実に実行する社員といったことのほうが真似もできないので競争優位の源泉になっていると思うのです。

モノは商品そのものであり、そこに付随する技術力だとかブランド力が入ってきます。現代ではこのブランド力などはずいぶんと重要な経営資源となっているでしょう。さらにモノには設備なども入ってきます。設備産業では、生産、輸送、格納、通信といった設備の保有能力は大きな経営資源となります。カネは資金であり信用力とかいったものになります。

さて、最後の情報というのはいったい何を指すのでしょうか。もちろん情報は無形資産ですが、知的財産なんて言われ方もします。でもこれだと特許だとか商標などを思い浮かべますが、それはむしろモノに付帯したものと考えたらいいのではないでしょうか。したがって、もっと広くとらえ、普通に事業活動で使われる情報全般を対象としたほうがいいでしょう。

いまの時代は、こうした情報マネジメントの重要性が増してきています。それは、顧客が求める情報の質と量の増大、そして一方で獲得できる情報のアクセスのリーチとスピードが格段に増したことがあります。ネットでグローバル情報資源から素早く有用な情報が取得できるようになっています。情報マネジメント力は大きな経営資源なのです。

ここで、ヒト・モノ・カネ・情報にもうひとつ加えたいと思います。それは、ネットワークです。現代のビジネスは孤立した会社が単独で営むことはできなくなっていて、さまざまな関係性から成り立っています。敵対的あるいは友好的、縦と横の関係、補完的あるいは下請け的などなど複雑に絡み合っています。そこに強みをもつことができたらそれは有効な経営資源となるのではないでしょうか。

ビジネスモデルを実行し成果を上げるにはこうした経営資源がきちんと整備されていてこそ可能になるわけで、下手するとここで足をひっぱられてせっかくのチャンスを失ってしまうこともあるのではないでしょうか。

ビジネスモデルの重要な要素にどうやって儲けるのかという収益モデルがあります。そこでこうした収益モデルのヒントとなる面白いメソドロジーを紹介します。書評でも取り上げた「ピクト図解」というやつです。この本では、ビジネスモデルと言っていますが、「収益モデル」というかむしろ「商流モデル」と言った方がいいと思います。

このメソドロジーでは３W1Hすなわち、「誰が（Who）」、「誰に（Whom）」、「何を（What）」、「いくら（How much）」で売って儲けるかを1枚の絵にまとめるという手法です。そして、この代表的な組み合わせモデルが８つのパターンになるというものです。

モデルを図解して見せるというのは非常にわかりやすくなるのでお薦めです。一番シンプルなモデルは単純な物販販売です。ビジネス主体が商品やサービスを製造・開発し、ユーザに提供してその対価を受け取るというモデルです。商材がメーカーからユーザへ行って、お金がユーザからメーカーに流れるだけということになります。

これは単純ですから、前に議論した「価値」ということでいえば、商品そのものに価値があるかどうかがポイントになります。差別化できるあるいは競争力のある商品であるかどうかです。

このモデルをベースにいろいろなバリエーションを付加していくと違ったパターンのモデルができていきます。例えば、作るところと売るところを分けたらどうなるでしょうか。ビジネス主体が製造と販売という二つになっていきます。

また、商品を売り切りではなく、その商品を買ってもらったあともその付属する消耗品も売れるというパターンもあるでしょう。こうした、商材とビジネス主体の組み合わせが様々な収益モデルを形成していくわけです。

このパターンを導出するには、箱を足したり、分割したり、線を増やしたりすればいいというものではありません。自社保有のリソースのパフォーマンスだとか他社との提携状況や商品の持つ特性だとかを勘案することが重要です。

こうした絵は、上述の「ピクト図解」を使ってもよいでしょうし、単純に丸と四角と矢印で書いてもかまわないと思います。要は、商材とお金の流れがわかることです。ただ、収益モデルというとほんとうはもう少しコストと価格という要素を入れる必要があるわけですが、モデル化の段階ではそうしたスペシフィックなものを入れるのも複雑性を与えてしまうので書かないでもいいでしょう。

それは、このあと出てくる業務プロセス設計で、価格決定メカニズムとかルールという機能として取り上げることになります。商流もさることながら、ここも非常に重要になってきます。特に、価値に価格競争力が出てくるとここがキーになります。
　　

業務システムの構成

このシリーズでもちょっと脇にそれた話題を提供していくことにします。いまここではビジネスモデルができたら、それをどうやって実際に動く業務システムまで落とし込むかがテーマになっています。このことを考える上で、やみくもにシステムにすればいいやというものではなく考察する角度もいくつかあって、その攻め方も違ってきます。

その主な構成は、構造的なもの、機能的なもの、そして、それの作り方の3つではないかと思っています。すなわち、システムの構造をどんな構造のものにしたらいいのかということ、そのシステムがもつべき機能はどんなものがあるのか、そしてシステム開発、システム構築はどうやったらいいのかということです。

いまのシステム作りはこのあたりの考察が足りないような気がします。単に要求をブログラムに書いてシステムができましたと言ってやしないだろうか。こうしたやり方だと、いつもいつも似て非なるものを同じように作っている可能性があります。

そして、上述の3つの領域で今の時代に要求されていることは何でしょうか。基本はビジネス側の要求を適確に途切れなく実現してあげるためにどうなのかという観点に立ちます。それは、次の3つではないかと考えています。

（１）ビジネスの構造を写像したシステム構造
（２）ビジネスの実相を表現できるシステム機能
（３）ビジネスの今を構築するシステム開発

システムは、ビジネスを実行するための組織や役割、リレーションシップなどをそのまま写し出したものであるべきです。ですから、会社の構造と対になったものでなくてはいけません。それが業務システムというものです。その次に、IT化を考えるという順番でしょう。

今のは構造的な問題で、次はそれを使って日常の業務をどうやって遂行するのかという話です。ビジネス活動をそのまま表現するというのが望まれていることです。実はここはそれほど議論されてきていません。ビジネス側とIT側のコミュニケーションができていないこともあります。

ここも再三言っていますが、オペレーションという概念が薄いことに起因しています。システムは動かして、成果をあげてこそビジネスに貢献できる役に立つシステムになるわけです。そのために業務システムが持つべき機能は何のかです。

そして最後のシステム開発の問題です。よく話題になる開発期間が長いという問題と手戻りが多いという話です。近頃のビジネスモデルはしょっちゅう変わるようになっていきています。そんな場合、システムが開発し終わったらもうそのビジネスモデルは古いなんてことが起こりえます。ですから、要求が決まったら即刻作ってあげる必要があるわけです。

さて、それぞれの領域での解決策は何でしょうか。それについては、本シリーズや「業務システムの再定義」などで示しています。簡単に言うと、コンポーネントベースの疎結合構造であり、2段プロセスと意思決定プロセスいう考え方によるプロセス設計であり、フレームワークを使ったアジャイル的組み上げ開発なのです。

ビジネスモデルの構成を考えてきましたが、すこし別の角度からということで、表現の場という見方で考えてみましょう。つまり、経営資源、プロセス、コントロール、オペレーションを行っているプラットフォームを考えることにします。ビジネス活動は、こうしたプラットフォーム上で実行されて結果をだしています。

経営資源については、前のエントリーで書いていますが、ヒト、モノ、カネ、情報、それとネットワークというものを加えています。最初に行ったビジネスモデルの定義の「提供するにあたって必要な経営資源をいかなる誘因のもとに集めるか。」のそのものずばりの経営資源です。

これらの、経営資源そのものがもつ優位性、例えば、効率のいい設備だとか優秀な人材や技術など、それとそうしたものの組み合わせがビジネスモデルを表現することになります。ただ、それを保有するだけではなにもなりませんから、どう活かすかがカギななります。プロセスやオペレーションと密接に絡んできます。

プロセスは、アクティビティの流れやそれを誰にやらせるかといったところに表れてきます。たとえば、冗長的でないシンプルなプロセスになっているとか、自社でやるよりコストの安い外部にアウトソースしたほうがよいとかいったことになります。

コントロールでは、プロセスにおける業務進捗の停滞や手戻りあるいはリスクの監視といったところです。こうした制御は直接的なビジネスモデルの表現には結びつかないかもしれませんが、結果的に効率的な価値提供プロセスを実現することになり競争力を持つことになります。

実は最後のオペレーションというところに競争優位の源泉が多くあると思います。プロセス構造や経営資源が静的な差別化要因だとすると、オペレーションが動的な差別化要因となります。日々の業務における各局面でさまざまな判断を迫られているわけですが、そこでビジネスモデルに合致した的確なアクションを行うことでビジネスモデルと業務プロセスが融合したことになります。

こうしたオペレーションという動的な要素を重要視した考え方はいままでにあったでしょうか。いくらすばらしいビジネスモデルでも形だけ作っても何もなりません。現場で人がそのとおりに動いたり、日常業務のアクションに反映されてはじめて活かされるのです。

次回から、業務プロセスという切り口で考えていきます。ビジネスモデルの表現として、まずは業務プロセスの構成要素に埋め込み、それを使ってコントロール、オペレーションを行って、ビジネスモデルを実行するという見方になってきます。

これまでビジネスモデルというのはどんな要素から成っていて、どういう構成のモデルとなるのかをみてきましたが、そのビジネスモデルを実行するために業務プロセスという形に落とし込むことになります。

その前に注意しなくてはいけないのが、ビジネスモデルを創造するプロセスとビジネスモデルを実行するプロセスとを混同しないようにすることです。これからやろうとすることは、できあがったビジネスモデルをどのようにして業務プロセスに落とし込むかですので、後者の実行プロセスが対象となります。

もちろん、新しい商品アイデアを創造することや、斬新な物流経路を編み出すといったビジネスモデルを創造するプロセスは大事なものですが、ここでは、そうした価値が作りだされたという前提に立ちます。

つまり、誰（市場）に対しての誰（市場）が決まっていること、どんな価値のその価値が定まっていること、どのように供給のどのようなやり方がおおまかに決まっていること、儲けるための仕掛けが決まっているところから始まります。こうしたビジネスモデルをどうやって実行させるのかが焦点です。

そこまで決められたらすぐにシステムになるのではと思う人もいるかもしれませんし、パッケージをもってくればやってくれるんじゃないという人もいるかもしれません。そうでしょうか。まだまだ抽象度の高い、あいまいな仕様でしかないはずです。そのまま動くものが作れません。これからは、そうしたあいまいさをもったビジネスモデルですが、それをくずさないように実装にまで落とさなければいけないことが求められます。

そして、ビジネスモデルからのアウトプットを武器にして事業を執行するために重要な役割を担うのが業務プロセス管理です。その内容を定義すると、「特定された顧客に対し、適切な経営資源の組み合わせで、最適な業務プロセスを設計し、適正なコントロールの下に優れたオペレーションを行うこと」となります。ここからは、狭い意味のプロセスからここに示したような広義の意味をもったものとして業務プロセスと言うことにします。

この、“特定された”、“適切な”、“最適な”、“適正な”、そして“優れた”というのが、他社と差別化するため、あるいは競争で優位に立つための必要条件となるわけです。しかし、これでは抽象的なので具象化しなくてはいけないのですが、かなり難しそうですね。

プロセスへの落とし込みの前に少し整理しておきましょう。まず、どんな価値なのかによって、主に表現するべき業務プロセスが変わってくるし、重要性も違います。どういうことかというと、価値には大きくわけて、商材そのものに埋め込まれたものと、汎用的な商材だがその供給のし方に価値があるという場合があります。前者が“価値ある商材”であり、後者が“価値あるプロセス”ということができます。

商材とプロセスの関係を書くと次のようになります。
（１） 価値ある商材と経済合理的な供給プロセス
（２） 商材は汎用的だが競争力のある供給プロセス
（３） その両方

ですから、価値のあり方によりプロセスの強弱や色合いが変わってくるのでその辺を頭に入れておく必要があります。

ボトムアップもいいかもしれない

「ビジネスモデルを実装する」では、ビジネスモデルから落とし込むのでトップダウンの手法であると言える。しかし、詳細レベルに行けばいくほど難しくなってきて、結局、ボトムアップで考えたものと突き合わせることをしている。

業務プロセスの構造と機能から、そのどこにビジネスモデルの要素を埋め込むか、言い換えれば、ここはどうしたらいいのかを上流に問いかけるというやり方である。そうすると、上流設計で不備なことだとか、あいまいなことなどだ浮かびあがるというわけだ。チェックリストを埋めていく方式に似ている。構造的、機能的な空欄を埋めてもらうのだ。

それを敷衍してみると、いま議論しているビジネスモデルも
１．誰に、どんな価値を提供するか。
２．その価値をどのように提供するか。
３．提供するにあたって必要な経営資源をいかなる誘因のもとに集めるか。
４．提供した価値に対してどのような収益モデルで対価を得るか。

というような、かなりメタレベルだが構造化してあるので、ここからボトムアップ的に事業戦略とか経営戦略を考えたらどうかという話である。つまり、“誰に”を決める時、どんな戦略的な意味から決めたのかとか、収益モデルはどういう会社にしたいからそういう選択をしたのかといった問いを発するのである。

マイケルポーターの競争戦略だとかボストンコンサルティングのppmを持ちだすまでもなく、SWOTでもBSCでも、こういった上流で一生懸命考えたことを下におろすより、なんか下から行った方が現実的ような気もする。経験的にも経営戦略といったって考えるやつは経営者でもないのであって、つい現場的な見方を入れてしまう。それなら、ボトムアップでいいじゃないかということである。

例えば、BSC（バランススコアカード）との関係で見ると分かりやすかもしれない。ご存知のようにBSCは、財務の視点、顧客の視点、業務プロセスの視点、学習と成長の視点の４つから総合的に企業を評価しようとするものです。そしてそれぞれでKPIを決めて管理するわけです。

これこそ、先に書いたビジネスモデルそのものです。すなわち、誰にどんな価値は顧客の視点ですし、価値をどのように提供するのかは業務プロセスの視点で、経営資源は学習と成長の視点なのです。そして、収益モデルは財務の視点になります。ただ、価値とはという視点がないように思うのですが。

このBSCの手順はどうなっているのかというと、ビジョンの決定、戦略の決定、CSF、KPIというふうになっています。ですから、ここでも遡ったらどうだろうか。つまり、ビジネスモデルから、KPI、CSFにいき、戦略、ビジョンへ辿りつのである。

しかし、これだけでは無理がありそうなので、戦略、ビジョンの確認といったことでいいのかもしれない。トップダウンとボトムアップの併用であるハイブリッド型のアプローチが現実的なのである。

今回からもう少し具体的に業務プロセスに落とし込んでいきます。まず初めに、ビジネスモデルのアウトプットとそれが実行されるための構成モデルとの関係をみてみましょう。

主なものはつぎの3つになります。
（１） 顧客／市場　　・・・顧客接点モデル
（２） 価値　　　　　・・・価値供給モデル
（３） 商流／価格　　・・・収益モデル

さらに、このプロセスを実行プロセス的にもう少し分解してみましょう。

（１）商品認知・顧客囲い込みプロセス
（２）リソース調達・商品供給プロセス
（３）代金請求・回収プロセス
（４）経営資源管理プロセス

といったところでしょうか。商品認知・顧客囲い込みプロセスというのは、いくらいい商品を作ってもそれを知ってもらって、買いにきてくれなくてはビジネスにはなりません。そのためのプロセスです。

リソース調達・商品供給プロセスは、文字通りオーダーをもらったらそれに対して迅速に出荷しなくてはなりません。そのために、必要な調達や品質管理、輸送管理といったものも含めたサプライチェーンのような仕組みになります。

残りの二つはもちろん大事なプロセスですが、ビジネスモデルを表現するという観点からいうとそれほど重要ではありません。差別を実現する意味合いが薄いということです。商流はスキームを作ることでおおかたの役目はおわりますし、代金請求・回収プロセスはリソース調達・商品供給プロセスの一部に含めればいいのです。

経営資源については、プロセス実行には必ず付いてまわるという意味で、それ自身には大きな意味がありますが、管理プロセスという点でいえば定型的なワークフローなのです。

ということで、主に商品認知・顧客囲い込みプロセスとリソース調達・商品供給プロセスのどこにビジネスモデルの差別化すべき各要素を “表現”させていくのかということになります。

これまでの業務システムは、こうしたアプローチをしたでしょうか。ビジネスモデルを表現するものとしてあったでしょうか。どうも、乖離があったように思うのです。IT化できるところだけITでやらせて終わりだったのではないでしょうか。このビジネスモデルの“表現”は、何もITにやらせなくてはいけないというわけではありません。あくまで、ビジネスモデルと業務プロセスの一貫性の維持が重要なポイントなのです。

前回、ビジネスモデルの各要素を業務プロセスのどこに“表現”させていくのかという課題について議論しました。そして、それを表現するプロセスとして主に、商品認知・顧客囲い込みプロセスとリソース調達・商品供給プロセスということを提示しました。

そこから更に細かく構造化していきたいのですが、それはかなり難しくなります。そこで、業務プロセスそのものが持つ構造から考えることにします。つまり、業務プロセス側からここのところで“価値”を表現したらどうかという逆からのアプローチです。

業務プロセスの構造というのは、簡単に言うと基本骨格として、始点と終点があって、その間をアクティビティの連鎖でつないでいくという構成になっています。そして、そのアクティビティを処理するために必要なリソースを配置してあることなのです。

このように考えると、マクロ的なプロセスを想定すると何のことはない商品認知・顧客囲い込みプロセスが始点で、リソース調達・商品供給プロセスが中間のプロセスで代金請求・回収プロセスや経営資源管理プロセスが終点とみなすこともできるのです。ですからプロセスというのは階層的な入れ子構造になっているのです。

さて、そのプロセスを一般化した構造で表すと、依頼―依頼受付―単位意思決定―作業―報告・登録となります。プロセスの始まりは何らかの依頼から始まり、その依頼されたことの答えを一つずつ決めていき、依頼を実行するための作業を行い、答えを返してあげて実績として登録するというステップです。LAP（Language/Action Perspective）理論では、要求―約束―実行―宣言―受理となっていますが、基本的には同じようなことです。

上に挙げた始点から終点までの各アクティビティの中の処理は意思決定を行っていることに他なりません。依頼にしても、依頼者がそこに依頼するという意思決定をしているわけです。顧客が購買行動を起こすのもそうです。そして、それを受付けるかどうかも同様に意思決定になります。

この意思決定という行為はどんなふうに行われるでしょうか。サイモンの意思決定プロセスでは、情報活動（情報収集）―設計活動（代替案の探索・評価）―選択活動（代替案の選択）―検討活動（代替案の実施・フィードバック）と言っています。この繰り返しが業務プロセスであり、実際のビジネス活動であると考えられます。

こうした一連の動きで実際に何をしているのでしょうか。最初の情報活動では、意思決定を行うために必要な情報を集めてきます。そして、そうした情報を基に代替案を設定します。その代替案をいろいろな基準やルールあるいは計算結果などにより評価します。最後に制約条件や規程に則ってチェックして承認するわけです。

次回に、もう少し詳細にみていくことにします。

ConstructionとFunction

以前にご紹介した「DEMO」という理論を展開しているオランダのDietz教授が言っていることである。日本語では“構成”と“機能”である。この二つを明確に区別して考えろというのである。そして、同一性ということやシステムの概念モデルについて次のようなことを述べている。

合成オブジェクト（composite objects）の変化を取り扱うために、2種類の同一性を区別しなければならない。すなわち、機能の同一性（sameness of function）（すなわち、その機能を遂行する能力を持つまとまった全体）と構成の同一性（sameness of construction）（（すなわち、部品の配置）である。例えば、車のある部品が他の部品で置き換えられた時には、機能の同一性は保たれる（ので、同じ車である）が、構成の同一性は保たれない（ので、同じ車ではない）。われわれは、合成オブジェクトに関して、機能タイプ（function type ）と構成タイプ（construction type）を区別する。したがって、ある新車が生産された時、2つの実体が産み出される。すなわち、機能的な実体が構成的実体によって実現されるのである。

White Boxモデルは、オントロジカルシステムの定義を直接概念化したものである。それは、システムの構成観点に対応している。Black Boxモデルは、システムの機能観点に対応している。それは、実際、目的論的システム概念と軌を一にするものである。

ちょっとわかりにくいかもしれないので、車の実例で補足すると、Carは、chassis、wheels、motor、lampsなどから構成されているのをWhite Boxモデルと言います。一方、Black Boxモデルでは、lighting System 、power system、steering system、brake systemから成りたっています。この機能と部品の違いがおわかりだと思います。

こうして機能と構成を線引きして考えることが大事で、そうすることによってシステム構築では4つのフェーズにわかれる。すなわち、機能設計、構成設計、工学設計、そして実装である。

このそれぞれのフェーズの受け渡しをどうするのかがポイントとなるのだが、「DEMO」では、後ろの工学設計、実装のところが示されていないので、「Kailas」で何とかできないかというあたりを模索しているのである。

さて、前回の引き続きでプロセスの構造を吟味していきます。サイモンの意思決定プロセスをみてもわかるように、プロセスの進行には主に情報を参照したり、処理したりといったように情報という要素をハンドリングすることで行われます。まずはこれが基本です。

なぜこんなことを言うのかというと、この参照情報を作るところまで組み入れてはいけないとことを強調したかったのです。つまり、生成された情報のみをみればよくて、例えば設備の稼働情報が欲しいとなったとき、設備管理システムまで組み入れてはいけないということです。在庫情報と在庫管理システムは別にするということです。

SOAでいうサービス化です。プロセスの進行に必要な情報提供サービスを受けるという感じになります。設備管理システムや在庫管理システムはいわば情報生成・提供というサービスコンポーネントとみなすことができます。それらをAPI化して結合するというふうになります。

ということでます情報という切り口でみていくと業務プロセスに必要な情報は何があるのでしょうか。それら全体を参照情報ということにすると、その中も情報の性格によって分類することができます。次の3つの種類があると思います。

（１） 事実情報
（２） 判断情報
（３） 制約情報

事実情報というのは、手持ちのリソースは何があるとか、履歴はどうだったか、顧客の住所はどこかといったマスタデータのような情報のことです。判断情報は意思決定するときの基準などやシミュレーションしてみた結果などになります。最後の制約情報は法規や規制などで経営理念なんかもこれに入ります。

さて、これだけで十分でしょうか。もう少し要りそうですね。いま判断情報と言いましたが、ここはかなり重要なところで、その中にルールというものがあります。このルールを広義に見た方がいいように思います。要するに、いろいろなところにルールが入り込んでいます。ルールについては次回に詳しく議論します。

情報以外では、誰がそのプロセスに責任を持って実行するのかという、ロールと権限というのも必要です。ロールというのはプロセスのなかのアクティビティをだれ（どこの組織）が受けもつのかということで、よくスイムレーンを書いて表現します。権限というのは、起案、確認、承認とかいった機能です。

こうして見ると、業務プロセスの構造を形成している要素は、もちろんアクティビティとそのフローは言うまでもありませんが、その周りに参照情報、ルール、ロール／権限を配置するというイメージになります。

前回は、業務プロセス構造について、少し長くなりましたが参照情報、ルール、ロールなどについて議論しました。さて、ここからはビジネスモデルの各要素を業務プロセスのどこに反映させるかという話になります。おさらいとして、ビジネスプロセス要素とは、顧客／市場、価値、経営資源の組み合わせ、供給プロセス、収益モデルです。

そして、この中でも「価値」をどう表現するのかが難しいところになります。すなわち、価値とは他との差異ですから、その差異、これももう一度おさらいですが、比較優位性、特異性、新規性をどこに埋め込むかになります。

今までの議論で、構造や構成といった静的な部分に現れる場合にしても、コントロールやオペレーションといった動的な部分に反映させるにしても、どうも何かの決めごと、すなわちルールとか規則として表現しているように思います。ですから、広義の意味のルールに集約されるように思っています。

さて単にルールというと、if then else 的な狭義のルールを思いがちですが、もう少し広い意味にとらえることにします。ですから、このルールは業務プロセス全体にかかるものだとも言えます。つまり、プロセスの構造とシーケンスを決めるためのルール、アクションを起こす基準となるルール、ロールや権限の決めるためのルール、情報の意味を規定するルールといったものになります。

そして、こうした広義のルールを管理する仕組みが必要になります。ただこう言うとそれはルールマネジメントでしょ、今あるじゃないですかと言われるのであまり使いたくないので、“コントローラー”と呼ぶことにします。この用語にしたのは、ルールをマネジメントすることが目的ではなく、ルールを適用してうまく業務プロセスをコントロールするということです。

コントロールという概念をもう少しみていきましょう。どういうふうにルールがかぶっていくのかを具体的な例でみてみます。例として、与信限度額について考えます。

オーダーが来たらそれを受けていいのかどうかというチェックはよくやられます。その時のチェック条件に与信限度額というのがあります。取引きする相手の信用度に応じて受けるかどうかを判断するわけです。その時のルールはどうなっているでしょうか。

まず、与信限度額というものを定義しておかなければいけませんね。その辞書的な意味は当然ですが、その限度額そのものの値もあります。それは一律に決まるわけではなく、例えば、普段から何回も取引きがある会社とそうでないところとか、会社の信用度とかで、その値の決め方すなわちルールが設定されます。

次いで、限度額が決まると、その限度額を超えるなら拒否するのか、再審査するのかといったルールもあります。また、その時、相手に知らせるのをメールで返信するだけにするとかというふうに、どういうプロセスで対処するのかという決めもあります。

ということで、単純なルールもありますが、多くはプロセス定義に関係するもの、データ定義に関係するもの、オペレーションに関係するものなどそれぞれに関連し合う構造になっています。ここにこそ、ビジネスモデルの重要な要素が埋め込まれています。

上記の例でも、ハイリスクハイリターンでいくといったビジネスモデルだとすると、信用度の低い会社とも積極的に取引をして、多くの顧客を獲得できるような与信限度額の設定になるわけです。
　　

日本のビジネスモデルは強い

このシリーズの主題は言うまでもなくビジネスモデルをどうやったら実装モデルに表現し実行できるかということである。従来の業務システムの構造や機能ではそれができていないという問題認識から議論を展開したいということである。

そのことがなぜ重要なのかを考えてみたい。単純にビジネスの実相をそのままITに載せるというのももちろん大事なことであるというのは言うまでもないが、もうひとつの視点としてグローバル競争力という切り口もあるように思うのである。

今の日本のIT業界の停滞は奈辺からきているのだろうか。わが国SIerはインドと中国、最近ではベトナムとかフィリピンとかそういった国々とシステム開発コスト競争をしているように見える。それでは勝てないし、細っていくだけだろう。

グローバルで戦うには、当たり前のようにグローバル競争力が無くては戦えない。そうだとしたら、その競争力をどこに求め、どのように身につけでいくかが問われる。何も武器を持たずに戦闘になんかでられないのだ。

日本のIT産業がもつグローバル競争力とはいったい何か。それよりもそんなものがあるのかどうか。みなさんどう思いますか。ソフトウエアとかプログラム製造力といったところではかないそうにありません。

そこでもう一度業務システムとはどういうものかを考えてみてください。このシリーズのテーマでもあるようにビジネスモデルをそのまま実装したものです。であれば、このビジネスモデルそのものに競争力がないのだろうかと思いつくはずです。そこは、日本の強い企業にはすばらしいビジネスモデルが数多くあります。

ユニクロ、セブンイレブン、クロネコヤマトなどに限らず中小企業も含めて様々な分野でユニークで優れた事業を展開しています。このビジネスモデルとセットとなったビジネスプロセスとそれをオペレーションするプラットフォームは十分にいや先進的なものとして世界に通用すると思うのですがいかがでしょうか。

ITは要素です。システムは道具です。道具はどんな使われ方をするかでその道具の価値がきまります。強い、競争優位を実現するビジネスモデルを生かせる業務システムの提供こそこれからの日本のIT産業がめざすことではないでしょうか。

前回、コントロールという概念とそれを実行するコントローラーということを提示しました。さて、お気づきかもしれませんが、コントローラーと聞くとMVCモデルのCであるControllerを思い浮かぶ人がいるかもしれません。そこで、MVCモデルの業務プロセス適用を検討してみます。

ご存知のように、MVCモデルというのはソフトウエアの設計において、Model、View、Controllerという３つの要素から構成されるモデルのことである。Modelというのは処理のためのロジックやデータで、Viewは画面表示をする。そのModelとViewを制御するのがControllerである。

リクエストがくるとそれをControllerが受け取り、Modelに処理要求、Viewに表示要求を出します。Modelでは処理とデータベースの更新を行い、そのデータをViewが参照して表示するという動きになります。

これらの機能が別々に独立的に分離されていることが重要なのですが、このモデルを業務プロセスモデルに当てはめてみましょう。まずは、マクロフローの部分をみていきます。マクロフローというのは、依頼－依頼受付－単位意思決定－作業－報告・登録という動きになっています。

この場合、Viewの部分がどうなっているのかということがあります。別に画面でなくてもいいのですが、業務システムと考えると最近はWebブラウザというふうにみてよいと思います。ですから、依頼を受付けるWebページがViewになります。受付けるかどうか、あるいは受付けるとなったら、それを次の意思決定アクティビティに渡すのと、どういうふうに依頼に対する回答を用意したらいいのかを決めます。これはControllerの役目になります。そこで決められたロジックで処理され、データを確定します。まさにModelとなります。そして、ここで確定されたデータや作業結果をWebで表示します。

こうしてみるとシステムの基本的な構成がマクロレベルの抽象度でもMVCで表現できるのです。では、ミクロレベルではどうでしょうか。ミクロフローというのは、単位意思決定アクティビティのデータ確定処理です。

ここでのリクエストは単位意思決定アクティビティにこういうデータを確定してくれというふうに来ます。それを受けるViewは、マクロでは顧客との接点ですが、この場合は内部で処理するための画面です。そのリクエストをControllerがバリデーションやフィルタリングなどを行い、意思決定のためのWork Spaceに処理要求を出します。ここは誰がどんな情報を参照してデータ確定するのかというロジックとデータをもったModelになります。その処理結果が終わるとViewであるアクティビティの完了表示となります。

さらに、その下位レベルである参照情報の取得も同様にMVCで考えることができます。ただ、あまり厳密なものとせずに構成要素的に似たようなものだという解釈でいいと思います。こうしてみると、業務プロセス自体もMVCモデルのように記述できるわけで、そうしたほうが一貫性をもって、実装に落とせるような気がしています。

ただ、Controllerの役割と機能はアルゴリズム的な要素もあったりして難しいのですが、ここをうまく整理できると非常にわかりやすいシステム構造になり、ということは簡単に作れるし、何よりもビジネスモデルを埋め込みやすくなると思うのです。

前回、業務プロセスのMVCモデルとの類似性に言及し、そこで重要な要素としてコントローラーということを提示した。どうもビジネスモデルにおける競争優位の源泉とか差別化要素などを埋め込むには、コントローラーという概念が受け皿としてウエートが高くなるように思われます。したがって、その辺について考えてみましょう。

コントローラーの機能をかいつまんで言うと、リクエストの受付方、モデルへの渡し方、モデル内での処理のしかた、データの扱い、結果の表示のしかたをコントロールすることになります。そのために必要なのは、制御アルゴリズムを生成するためのルールや基準、計算式といったものです。

ただここで注意しなくてはいけないのは、行動を規定するルールを注目しがちですが、制御対象となるデータや情報の定義ルールやその種別を表すルールといったものも大事になります。すなわち、動的なものと静的なものの両方があるということです。

例えば、顧客というのも定義がいるでしょうし、優良顧客も同じように定義しなくてはいけません。そして、顧客ができること、できないこともあります。また動的なものでは、初めてコンタクトしてきた顧客だったらこうしなくてはいけないというルールがあるはずです。

たった顧客というだけでも静的、動的の様々なルールがあることがわかります。こうしたルールを埋め込んでそのルールによって判断したり、次のアクションを誘導したりするのがコントローラーというものになります。

ですから、そこにビジネスモデルで定義した自社の強みや特徴を埋め込むことが多くなるということがおわかりになると思います。先の例でいえば、顧客はまさにビジネスモデルの「誰に」にあたるわけで、そこでセグメンテーションされた顧客だけを相手にするということになると、その定義から外れた顧客がアクセスしてきたら辞退するという行動になるわけです。

ただそれを体系的にパターン化するのは難しいということです。当たり前のようにこれはその会社の“個性”ですから、画一的な枠にはめるわけにはいきません。実際にはインタビューによって、どこにどん形で表現したらいいのかを個別ケースごとに設定していくことになります。

次回は、このルールも実は階層的であるというお話とコントローラーに表現するための整理の仕方を考えてみます。
　　

業務プロセスを実行する場合にかなり重要なものにルールをベースにしたコントロールというものがあります。そしてこのルールという概念はさまざまなところに出てきます。しかも、単純な狭義のルールだけではなく、言葉の定義から方針のようなものまで幅広くとらえる必要があります。

それでは、まずはどんなところにルールが使われるかを見ていきましょう。業務プロセスを実行するというのは、ごく簡単にいうと、ある依頼（要求）に対して、その依頼に答えるため、いろいろなリソースや情報を使って、単位意思決定をしながらプロセスを回して、最初の依頼に対する報告（回答）をすることです。

この過程を見ていくと大きく次のようなところにルールが使われることがわかります。

（１） プロセスフローの定義のためのルール
（２） データ定義のためのルール
（３） オペレーションのためのルール

（１）のプロセスフローの定義のためのルールというのは、プロセスの中にある必要とするアクティビティとそのアクティビティの順序あるいは分岐のルールなどです。例えば、検収の方法だとか、注文書の発行手順だとかいったものです。そして、プロセスフロー設計のときにこのルールを参照しながら、プロセスフローを描いていきます。

（２）のデータ定義のためのルールは文字通りデータとか用語を定義するものです。ここは意外と重要なところで、このリソースを使ってと言ってもその解釈がばらばらだったり、会社内でも同じ言葉を使っていながら内容が違っているなんてこともあるわけです。逆に、同じ意味なのに言葉がまちまちだったりします。例えば、同じ中間製品なのに半製品といったり仕掛品といったりします。

これらは、単なる氏名、住所といった定義の必要ないものから、メタレベルのデータもあります。例えば、優良顧客なんて言葉があったりしますが、何をもって優良なのかを定義しておかなければいけません。こうした定義を階層的にデータ辞書みたいなものに整理しておく必要があります。

（３）のオペレーションのためのルールは、アクションを誘導するためのものです。つまり、対象となる値や事象が設定した水準になったときとか、要求が制約にひっかかったらどういうアクションを起こすかを決めることです。例えば、基準最少在庫に達したら在庫補充を行うとか、与信限度額を超えたので拒否するといったことです。

このとき、その基準値も定義しておかなくてはいけません。基準となるあるいは制約となる値そのものでその会社や事業の方針が表れてきます。管理している対象は同じでもその基準値で競合会社と差をつけるなんてことがあるので重要になってきます。

前回はルールがどこで使われるかをみてきましたが、今回はちょっと違った見方で見ていきます。次に示すように、大きく３つの構文（文法）が浮かびあがってきます。

（１） A　is　B　（to　do　B）
（２） A　can（must）(not)　do　B
（３） If　A　is　B　then　C　else　D

（１）というのは静的な言葉の定義になります。例えば、仕掛品とは「材料から製品になる過程の中間的製品で、かつ、そのままでは販売できる状態ではないもののこと」といった表現になります。ここでは名詞だけではなく動詞についての定義もします。在庫引当とはとか発注とはどうすることかと言ったことです。

ただ、今言ったことだとかなり一般的な定義ですので、実際にはもう少し固有的な言い回しの方がいいように思います。わが社では、何々の工程までの中間製品を仕掛品とよぶといったことです。

それと、形容詞、形容動詞がついたものの定義も要ります。例えば、優良顧客とはどういう顧客のことなのか、この優良の意味は、緊急出荷とはどういうことをいうのか、緊急の定義はといったことになります。ここはけっこう重要できちんと決めておかないと担当者ごとに違ったり、その都度の判断になったりして、業務の質や効率性に問題が出てきます。

（２）は、できること、できないこと、しなければいけないこと、してはいけないことを規定したものです。（１）ではそのものを定義したわけですが、ここではその定義されたヒト、モノあるいはコトが何ができるかを定義しています。例えば、月に5回以上注文が来る顧客を優良顧客として定義したら、この優良顧客は与信チェックなしに注文を受けてもらえるといったことです。

また、ロールや権限という考え方もここでのルール設定に従うことになります。責任と権限の所在をはっきりさせることが大事なことです。

最後の（３）は、よく使われるif then elseで表すルールで、もし○○が△△だったら、こう言うアクションを起こす、そうでなかったら違うことを行うというやつである。（１）と（２）の静的なものではなく動的なルールとなります。

結局、こうしたリソースそれぞれのもつ意味や役割、義務などを定義した静的なルールとそれらがアクションを起こす場合の条件やきっかけを定義した動的なルールの組み合わせでルールが構成されているのです。さらに、そこには汎用的、一般的な定義の仕方とその会社あるいは事業、業務に固有のよりスペシフィックなものがあります。

この階層的な捉え方をすると前者をLaw、後者をルールと呼びたいのですが、実は今はその区分けはそれほど重要とは思われないので、詳しくは言及しませんが実地にやってみて再検討しようと思います。

改善と改革

この言葉の違いはおおかたの人はわかっていると思うが、単なる言葉の意味の違いではなく、実際にどう実行するかという点で意外とわかっていないのではないかと思うことがある。つまり、改善も改革も同じようなアプローチをするということである。

よく見かけるのは、業務改革プロジェクトとかプロセス改革委員会とか言って始めるのだが、おそらくほとんどのケースで現状分析して、そこでの問題点を洗い出しましょうなんてことをやる。

いわゆる、AsIs分析である。そこから、ToBeと導き出そうという進めかたである。一見よさそうに見えるし、まったくダメだというわけでもないので、ついこうしたアプローチがまかり通るがちょっと考えてみる必要があると思う。

現状分析から問題点を抽出してというのはいわゆる問題解決型のアプローチであるが、これだとどうしても現状に引っ張られてしまい、斬新なそして画期的なアイデアが生まれにくいという欠点がある。ただし、この場合の問題点の設定が非常に適確で当を得たものであると改革的な答えにたどり着く可能性はある。議論のかみ合わないことが起こるのはこの問題設定が間違っている場合が多いのである。

こうした問題解決型の対極は仮説検証型であるが、このほうが改革には向いているだろう。現状にあまりとらわれずにこうしたほうがいいという仮説を設定して、そこに行き着くためにどうしたらいいかを考えることである。ただここでも、この仮説の立て方が問題で、この設定に左右されてしまうのは問題解決型と同様の悩みである。

ですから、改革のアプローチは現実的には両者の中間に解があるように思う。すなわち、現在の問題を意識しながら、そこからの連続ではなく、少し“跳んだ”仮説をいくつか立て、それをケーススタディ的に検証して、その中からBetterケースを選択するというアプローチではないでしょうか。

さて、ここで業務プロセス改革ということについて考えてみます。現状業務プロセスすなわちAsIsプロセスを書き出して、それをToBe化しますというのは多くの場合プロセス改善です。ではプロセス改革はどうしたらいいのでしょうか。

実はプロセス改革は、プロセスのところだけでは改革はできません。せいぜい改善でしょう。プロセス改革とはビジネスモデル改革と一対のものなのです。他社と差別化する新規のビジネスモデルができ、それを実現するためにプロセスを改革するということなのです。新しい価値を生み出さなければ改革ではないからです。

従って、業務プロセスの重要な役割は、ビジネスモデルの変革に素早く柔軟に対応できるものでなくてはいけないということです。そのためには、AsIsからToBeということではなく、プロセスの構造の本質を見極め、すぐにデザインできることであり、変化対応力のある構造と機能を持っているということなのです。

このシリーズも勢いよく始めた割には尻すぼみ感は否めないのですが、いちおうまとめのようなものを書こうと思います。もともとの主題は、ビジネスモデルとはどういうもので、それを実行するための業務プロセスはどうあるべきかといったことでした。それをある程度の類型化あるいは形式化することができるかどうかであった。

結果的には、ビジネスモデルの構成や業務プロセスのどこにそれを表現するのかといったことは何とかできたと思うのだが、具体的なフォーマティングはむずかしかった。やはり、事例ごとの個別の積み重ねがそれを可能にしてくれるように思います。

さて、最後にもともとボトムアップ指向できているので、ビジネスモデルありきでアプローチしていたのですが、ビジネスモデリングというのはどうしたらいいのだろうかということをかじったのでそのことについて書く。

業務プロセスモデリングもそうなのだが、多くのひとがおっしゃっているのはごく表面的であったり、かなり抽象度の高いお話ばかりで、実際に本当に具体的に設計するやり方は教えてくれない。ここができてこそ工学的なアプローチと言えるのである。

もう一度、ビジネスモデルの構成をおさらいすると、“どこの誰にどんな価値をどの経営資源を使ってどのように供給しどうやって儲けるか”です。このビジネスモデルの各要素を定義するためのチェックポイントを考えてみた。

どこの誰にというのは、顧客・市場のことで、やるべきことは市場セグメンテーションとセグメントの評価である。市場を細分化するために利用すべき変数は、「コトラ―のマーケティング入門」によれば、地理的変数、人口動態変数、サイコグラフィック変数（社会階層、ライフスタイル、性格など）、行動上の変数（使用機会、ベネフィット、使用者のタイプなど）になります。

そして、セグメントの評価をその規模と成長性、構造的な魅力、企業の目的と経営資源から評価します。このように上記の変数を勘案して顧客・市場の絞りこみをおこない、評価して「どこの誰に」を定義していくことになります。

次にどんな価値をになりますが、これも「コトラ―のマーケティング入門」に従うとポジショニングニングのところになりますが、価値をおくところとして、製品属性や、ベネフィットに基づき、また使用される機会、競合製品との関係において決めていくとなっていますしかし、もうすこしシンプルに、価値を商材そのものに埋め込むのか、その供給のプロセスに置くのかくらいでいいと思います。

さて、価値という場合、何をもって価値というかがあります。それは競争優位点があるのかどうかがわかりやすいと思います。つまり、競合他社との差別化です。その競争優位点、すなわち差異は、比較優位性、特異性、新規性になると考えています。

どのような経営資源と言うことでは、使えるリソースにはどんなものがあるかを考えます。いわゆる、ヒト、モノ、カネ、情報となりますが、そこにネットワークというのを加えてみたらどうでしょうか。現代は、グローバル規模の人や会社、組織との関係性が財産となっているように思います。

どのように提供するかは、業務プロセスとなります。この辺はさんざん議論してきたところです。そして、忘れてはいけないのがルールマネジメントです。プロセスとルールをセットでみていくというのが重要なことになります。

そして、最後のどうやって儲けるかは、商流モデルで、商品の流れとお金の流れを出し手と受け手の関係で示したものになります。

このようにしてモデリングされたビジネスを効率的に円滑に実行させるためにビジネスモデルの各要素を埋め込んだビジネスプロセスを回していくことになります。ここで重要なことは、ビジネスモデルとビジネスプロセスの一貫性と連動性です。これができてこそ、ビジネスの貢献するプロセスとなるのです。

そのために、ビジネスプロセスは、顧客接点モデル、価値供給プロセスモデル、経営資源組合せモデル、コントロール＆オペレーションモデル、そして商流モデルという要素から構成されている必要があるのです。おわり。