これまで、mark-wada blog　で"ボトムアップ戦略立案"というのと"ITエンジニアの育ち方"というシリーズで記事をエントリーしてきましたが、前者はほぼ完了したのと、後者も問題解決のし方や課題設定というフェーズが終わっって、これからその解決策を議論する段階になったこともあり、テーマを再設定して書いていこうと思います。

"IT エンジニアの育ち方"で出ていた課題が「事業に貢献できる業務システムとは」ですので、それに応えていくという流れになります。その答えを用意する役割を担うのが、"ビジネスエンジニア"(仮称)という呼び方をしようと思います。このビジネスエンジニア（BE）という名前はシステムエンジニア（SE）に並べるもので、システム構築の上流のパートを担当することになります。

実は、この領域のエンジニアはあまり多くないのではないでしょうか。最近では、BABOKで言及されたり、ビジネスアナリストとかビジネスアーキテクトなんて言葉もでてきていますが、BABOKは超上流と言われて、分析が主体でプロセス設計までの落とし込みが弱いと思われます。

ビジネスとIT との一貫性と連動性を担保できるシステムを設計する人が必要なわけで、これまではこの一貫性、連動性ができていないのと、それ故、そうしたデザインできる人材がいなかったのです。そのくせ、みなさんしゃあしゃあと経営とITの同期だとか、事業とITの融合だとかおっしゃいます。言うだけはだれでもできますが、実際に業務システムに落としこまない限り、意味がありません。

そこで、ビジネスエンジニアのやるべきこと、身につけるべきことについて議論するわけですが、前回にも指摘しましたが、「ビジネス」の定義を少し広くとっています。つまり、企業における事業だけではなく、イベントを実施する場合だとか、それこそボランティアみたいなことも含めて考えることにします。従って、定義は次のようになります。

「人々の要求に対して、それに見合う価値を提供することにより、相当の対価を得ること」

一方、エンジニアリングというのも定義しておく必要があります。こんなふうに考えてみました。

「価値を提供するための仕組みと仕掛けを設計すること」
こうして、ビジネスエンジニアが行った設計に基づいて、システムエンジニアがITの部分を担当することになるわけです。
　　

ビジネス実行体系

ビジネエンジニアというからには、ビジネスのことから考えていかなくてはいけないというのは自明のことです。従来、システム屋さんというのは概して、要件定義から入ります。つまり、ビジネス要求が決まってから、その要求に対してシステムをどう作ろうかというポジションにいるわけです。

ビジネスから要求を出す要求定義とそれを受けて行う要件定義との受け渡しが必ずしもうまくいっていないというのが、今の問題点ではないでしょうか。システムのことがよくわからないユーザが出す要求とビジネスのことがよくわからないシステム屋が受ける要件定義にギャップがあるのです。

では、そのギャップを埋めるには、それができる全く新しいスキルの人材を育成すればよいのでしょうか。そう簡単な話ではないですよね。その前に大事なことはその渡し方をどうするのかを決めないと人材も育てようがありません。ここらあたりはよく間違えるところで、順番は方法論を作ってから、その方法論にそって実行できる人材を育成するというのが順路であって逆ではありません。

ということで、まずはビジネスからシステム実装までの技法について考えていきましょう。ビジネスというと最上流のビジョンとか戦略というふうになりますが、そこは、理屈ではない部分や精神論的なところがあるのであまり深入りはしないようにします。まあ、トップダウン型の戦略はあるという前提です。

実際に行っているビジネスの実行体系は次のようになっています。

このうち、ビジネス構造の要諦はビジネスモデルだと考えています。そして、意外とこのビジネスモデルを書けていないというのが、このところ様々な事例をみての実感です。すなわち、SWOT分析したり、バランススコアカードを作ったりといった戦略策定みたいなことは、例えばその領域のコンサルタントを入れてやったりします。それと要件定義のところは最初に言ったようにシステム屋さんが待ち構えています。ところが、このビジネスモデルを誰が書くのかという大事なところがあいまいになっているように思うのです。

ビジネス実行体系の各フェーズの内容

前回は、ビジネス実行体系とその中の上流での肝はビジネスモデルであることを指摘しましたが、詳細に入る前に、提示した下記の体系にある各フェーズの内容について概観しておきましょう。

（１） 戦略
（２） ビジネス（事業）モデル
（３） ビジネス（事業）プロセス
（４） 業務プロセス
（５） 業務オペレーション

最初にある戦略ということですが、前回も言いましたが、戦略策定は通常トップダウン的に行われます。すなわち、企業理念やビジジョンをベースにして、様々な分析を行い、そのポジションに応じた戦略が講じられるわけです。しかしながら、トップダウン的だけではなく、ボトムアップ的なアプローチもあると考えています。それが、これまで書いてきた「ボトムアップ戦略立案」のことになります。簡単に言うと、ビジネスモデルに埋め込まれた自社の強みを生かして、どうビジネスモデルを変えていくのかも戦略になるということです。

さて、ビジネス実行体系の上流での要諦であるビジネスモデルということですが、ビジネスの基本的な構造と機能のモデルということになります。難しい言葉で言うと「組織能力」と「価値提供力」です。これも簡単に言うと、顧客を獲得してから、経営資源を使って、商品を提供して収益をあげる仕組みとなります。

ビジネスモデルは書いただけでは何もなりませんから、それをどう実行するかが大事なことになります。その実行の主体はプロセスと考えています。いきなり業務システムというようにはしないでください。ITはまだ出てきません。ビジネスプロセスを表現するのがビジネスプロセスということになります。

ただ、このレベルのものは、まだプロセスといっても、抽象度高い機能群を並べてものに近いと思います。そうした、ビジネスプロセスをさらに分解したものが業務プロセスです。ここでは、実行を意識した構造になってきます。そして、ここでプロセスという言い方をしていますが、業務システムというのは、システム機能を除けば、基本的にはプロセスだけではなくて、その他に、データ（情報）と機能（ユーザインターフェース）から成り立っています。

ですので、ここでは業務プロセスを広義に解釈して、それらを含んだ全体を業務プロセスと呼ぶことにします。つまり、データ（情報）を参照しながら、UIで操作して、プロセスを回して、新たなデータ（情報）を生成する仕組みと仕掛けを業務プロセスというふうに定義しています。

最後の業務オペレーションは、その業務プロセスを動かすプラットフォームのことで、業務処理案件が来たら、そこで受けて処理を行います。そして、その処理パフォーマンスを制御、モニタリングして、所定の効果を上げるようにします。モニタリングの結果で改善すべきことが出てきたら、業務プロセスの仕組みや仕掛けあるいはオペレーションマニュアルにフィードバックします。

実は、この最後の業務オペレーションという領域の重要性を感じることがビジネスエンジニアの重要なミッションとなります。従来では、ここが見落とされがちで、システムを作って終わりという例が多く見られます。

ビジネス実行体系の各フェーズの内容

前回は、ビジネス実行体系とその中の上流での肝はビジネスモデルであることを指摘しましたが、詳細に入る前に、提示した下記の体系にある各フェーズの内容について概観しておきましょう。

（１） 戦略
（２） ビジネス（事業）モデル
（３） ビジネス（事業）プロセス
（４） 業務プロセス
（５） 業務オペレーション

最初にある戦略ということですが、前回も言いましたが、戦略策定は通常トップダウン的に行われます。すなわち、企業理念やビジジョンをベースにして、様々な分析を行い、そのポジションに応じた戦略が講じられるわけです。しかしながら、トップダウン的だけではなく、ボトムアップ的なアプローチもあると考えています。それが、これまで書いてきた「ボトムアップ戦略立案」のことになります。簡単に言うと、ビジネスモデルに埋め込まれた自社の強みを生かして、どうビジネスモデルを変えていくのかも戦略になるということです。

さて、ビジネス実行体系の上流での要諦であるビジネスモデルということですが、ビジネスの基本的な構造と機能のモデルということになります。難しい言葉で言うと「組織能力」と「価値提供力」です。これも簡単に言うと、顧客を獲得してから、経営資源を使って、商品を提供して収益をあげる仕組みとなります。

ビジネスモデルは書いただけでは何もなりませんから、それをどう実行するかが大事なことになります。その実行の主体はプロセスと考えています。いきなり業務システムというようにはしないでください。ITはまだ出てきません。ビジネスプロセスを表現するのがビジネスプロセスということになります。

ただ、このレベルのものは、まだプロセスといっても、抽象度高い機能群を並べてものに近いと思います。そうした、ビジネスプロセスをさらに分解したものが業務プロセスです。ここでは、実行を意識した構造になってきます。そして、ここでプロセスという言い方をしていますが、業務システムというのは、システム機能を除けば、基本的にはプロセスだけではなくて、その他に、データ（情報）と機能（ユーザインターフェース）から成り立っています。

ですので、ここでは業務プロセスを広義に解釈して、それらを含んだ全体を業務プロセスと呼ぶことにします。つまり、データ（情報）を参照しながら、UIで操作して、プロセスを回して、新たなデータ（情報）を生成する仕組みと仕掛けを業務プロセスというふうに定義しています。

最後の業務オペレーションは、その業務プロセスを動かすプラットフォームのことで、業務処理案件が来たら、そこで受けて処理を行います。そして、その処理パフォーマンスを制御、モニタリングして、所定の効果を上げるようにします。モニタリングの結果で改善すべきことが出てきたら、業務プロセスの仕組みや仕掛けあるいはオペレーションマニュアルにフィードバックします。

実は、この最後の業務オペレーションという領域の重要性を感じることがビジネスエンジニアの重要なミッションとなります。従来では、ここが見落とされがちで、システムを作って終わりという例が多く見られます。

ビジネスモデルの記述と分析

前回は、ビジネス実行体系を概観しましたが、これからはもう少し具体的な構築方法について議論していきます。戦略については既に書いたことなので、まずはビジネスモデルをどうやって記述して、それを分析するのかというテーマとなります。実はこのテーマでも、以前「ビジネスモデルを実装する」と題して、書いていますので重複するかもしれませんが、より具体的に説明しておきます。

ビジネスモデルの記述・分析手順は次のようになります。

ビジネスモデルはつぎの切り口でモデル化をしていきます。

　・どこの誰に
　・どんな商材を
　・どの経営資源を使って
　・どのように提供して
　・どうやって儲けるのか

これで、ビジネスモデルが書けたかというとそうではありません。大事なのは、このなかに戦略的な要素がどう盛り込まれているのかになります。それは言い換えると、「価値」を埋め込んではじめてビジネスモデルということになります。ビジネスで競争していく上で勝てるものを持っていないとビジネスは成立しません。

また、このままだと抽象的ですので、それぞれをもう少し具体的な構成要素に分解します。それらにはどんなものがあるかを次に示します。

現状ビジネスの把握

ビジネスモデルの構成要素を理解したら、それぞれについて現状のビジネスにおける実態を記述していきます。市場や顧客であれば、今のビジネスがどのような市場で行っているのか、そのときの顧客をどうやって定義しているのかを書きます。セグメンテーションとターゲッティングです。

そのときの評価軸は自分で考えるのがいいのですが、このあたりはマーケティングの教科書に出ていますのでそれを参考にしたらいいと思います。商材については、従来だと割と単純で、単一製品だとか分かりやすいサービスといったものが主体でしたが、最近ではいろいろなものを組み合わせたものだとか、モノとサービスをセットにしたものとかが多くなっています。そのあたりをよく見てほんとうの商材を書いていきます。

この市場・顧客と商材が書きだせると後は比較的簡単ですが、ビジネスチェーン、サプライチェーンと商流モデルが混同される場合があります。前者はモノの流れで、後者はお金が絡んだものになります。

現状を記述する上で注意しなくてはいけないのが、この場合は事実情報を淡々と書くと言うことが大切で、変に曲げないことです。よく自分の思いだとか、こうありたいといった願望を含めてしまったりしますが、そうではなくて乾いた表現を心がけます。

こうして書きだしていくわけですが、このビジネス自体がどういうものであるかが明確になっている場合はそのあと強み、弱み分析に行ってもかまいませんが、そうでない場合は、ビジネスモデルの構成要素の重要度分類をして、そこからKSF（重要成功要因）を規定したほうがいいと思います。

すなわち、いま行っている事業というものを構成している要素の中でどれが重要なのかということをABCランクで表示します。例えば、商品の魅力という点が重要であるとか、化粧品のようにブランド力だとか、いや大事なのは設備能力や人材だというような評価を行い、その重要度に応じてABCに分けるわけです。

そして次に、そのなかでAランクに指定されたものを吟味して、さらに最も重要なものを選び出して行きます。これがいわゆるKSF（Key Success Factor）になります。ただし、気をつけなくてはいけないのが、それは状況によって変化するということです。内外問わず環境が変化した場合はこのKSFも変化しますので、その見極めが大事になってきます。

こうして、事業の成功のための重要な要件を頭の中に入れて、強みと弱みの分析に入っていきます。

この講座の「ビジネスモデルの記述と分析」でビジネスモデルの構成要素を記述していくようになっていますが、この前提が既存のビジネスありきになっています。つまり、いま実際にオペレーションしている事業があってそのことについて記述していくわけです。

ところが、そういうものとは限らないこともあります。例えば、新規に事業を立ち上げるなんていうのはそれにあたります。そのなかでも、既存の事業エリアがあってそこへ参入するなんていう場合はまだしも、全く新しい分野を開拓しようというときはどうするのかという問題があります。

おそらく、その場合の最大のポイントは商材の設定ではないでしょうか。どんな製品あるいはサービスを持って事業を構築していくのかということになります。顧客を先に決めてとか、強いリソースがあるのでそれを使ってとかいった考え方もないことはないと思いますが、それにしても大事なのは勝負する商材だと思います。

ですから、まずはそうした商材を創造するプロセスが必要になってきます。これはデザインプロセスになりますので、それ相応のやり方がありますが、慶應大学の奥出直人教授（ちなみにうちの社長の指導教授です）の「デザイン思考の道具箱」ではこう言っています。

ステップ１　哲学とビジョンを構築する
ステップ２　技術の棚卸とフィールドワーク
ステップ３　コンセプト／モデルの構築
ステップ４　デザイン－　デモンストレーション用プロトタイプをデザインする
ステップ５　実証
ステップ６　ビジネスモデル構築
ステップ７　ビジネスオペレーション

これと、ここで言っているビジネスモデリングの関係で考えていきましょう。ステップ１で事業コンセプトをきちんと定義することでそのあとステップ２でフィールドワークが入りますが、これは観察することを意味します。これからやりたいことが人々の行動とどう折り合うのかとか、人間の欲求とどうマッチングするのかというような検討をするわけです。
ステップ３では商材のイメージを作ります。ここで重要なのは、一番ポピュラーなのはKJ法やブレーンストーミングで発散的に様々なアイデアを出し、そこから収束させていくという方法になると思います。それとある程度のビジネスモデルを作っておいた方がいいように思います。

そして、そのイメージをより具体的に、詳細仕様化しプロトタイプを作ります。そこにはデザインという要素をしっかりと入れておく必要があります。こうしてできた商材を使って、ビジネスを行うためのモデル化を行います。これが、いまこの講座で議論していることになります。

ただ、このデザインプロセスは実践してみると少しばかり変えた方がよいと考えています。そのあたりについてはまた、waditとしての方法論を構築する中でカスタマイズしたいと思います。

現状ビジネスモデルの強みと弱み

さて、現状のビジネスモデルの記述とKSFの規定が終わったら、次はそれぞれの構成要素について、強みと弱みの分析を行います。ただ現状のビジネスの実態を記述しただけでは、ビジネスモデルではないので、そこにある価値をみていくことになるわけです。

この価値は、単純には強みということになりますが、弱みもマイナスの価値という風に捉えた方がいいと考えています。こうした、プラスとマイナスの価値が入ってはじめてビジネスモデルと言えるものができます。

ここで、価値には事業者側にとっての価値と顧客からみた場合の価値があるのでそうした見方をする必要があります。バランススコアカードにある顧客視点というチェックです。

少し先走りますが、この強みすなわちプラスの価値をさらに生かすのが戦略になり、弱みすなわちマイナスの価値をプラスに転化するのが、業務改善あるいはプロセス改革といったようなことになります。

さて、ここでは自分たちが思っている強み、弱みでいいのでそれを書いて行きます。ですから、現状記述と違って多少の恣意的な要素が入ってきてもかまいません。極端な話、勝手に思い込んでいることでいいわけです。それは後の競合分析で、自分勝手な思い込みなのかをチェックして客観化していきます。

ここで、構成要素にあるビジネスチェーンについてですが、これは会社間のモノの流れのことで、サプライヤーや販売代理店、顧客、アウトソーサーといったプレイヤーの関係のことになりますが、そうした広範囲のビジネスを行っている場合に書きますが、そうでない場合は書く必要がありません。

ここで、強み（プラス価値）と弱み（マイナス価値）が書けたら、次に競合分析に行きます。事業は必ず競争にさらされていますから、いつも相対的な位置関係を知っておく必要があります。これは、醒めた目でみることが重要です。場合によっては、第三者が行うのがいいかもしれません。

ここではまず、競業状況ということで、競合他社がどこかになりますが、つい同業で比較することをしますが、そればかりとは限りませんので、異業種とも照合する必要があります。例えば、飛行機の競争相手は航空会社内だけではなく新幹線かもしれません。

そうした、比較とともに差別化のポイントや競争優位の源泉を探っていきます。それを見る上で価値とは一体何なのかという観点が必要となってきます。それは前に書いたように、比較優位性、特異性、新規性という見方をします。

その結果、この事業がどこで価値を持っているので競争に勝っているとか、そこそこ平均以上だが、他社に比べて抜きんでていないとか、どれもが劣っているとかがわかってくると、その業界でのポジショニングが決まってくるわけです。

ビジネスチェーンの分析

今までは自社内のモデルについて論じていますが、少し大きな会社になってくると、それだけにはとどまらないで、他の会社との関連が出てきます。会社間の取引により、事業がなりたっているというケースです。おそらく現代では何らかの形で分業というのが一般的ではないでしょうか。

さらに、最近ではグローバルな形でも関連性が出てきています。サプライチェーンでも本社や研究開発などの機能は日本にあるが、生産は中国なんていうのは多くの例があります。空洞化は由々しき問題ですが、それはそれとして個別企業の生き残りの戦略としてしかたないのかもしれません。

さて、その関連性をここでは「ビジネスチェーン」と呼ぶことにします。バリューチェーンといった呼び方もありますが、このバリューの定義があいまいなところがあるので、簡単に各社のビジネスのつながりという意味でこうしたワーディングにします。

このビジネスチェーンについても必要に応じて、現状の記述・分析とポジショニングをしておきましょう。ビジネスチェーンに参加する企業は、調達先などのサプライヤー、アウトソーサーもこのサプライヤーに入ります。また、代理店のような販売業者、ネット何かだと広告業者なんかもそうかもしれません。それと顧客ですね。

そうした関係のある会社について、現状の記述・分析では、拠点がどこか、取り扱っているものは何か、取引形態はどうなっているのかといったことを記述していきます。取り扱い物も、原材料のようなものから、中間品や資機材、部品、そして商品といった区分になります。

それができると、分析に入ります。これも同じように強み、弱みの分析を行います。トヨタの強みは、大変忠誠心の強い部品業者がいるとか、ひと昔前の松下電器の全国展開された販売店なんていうのもそうかもしれません。ユニクロと東レの関係なども強いですよね。最近は、グローバルで評価しなくてはいけなくなりました。

そこから、これまた同じように競合分析を行い、差別化ポイントや競争優位点からポジショニングを行うことになります。自社を取り巻くビジネスチェーンが他社と比べて強いのか弱いのか、どういう位置にいるのかということがわかってきます。

この講座では、戦略のことに触れていません。ビジネスエンジニアには必要ないというわけではありませんが、戦略を立てられるような前振りをしてあげるというのが主なミッションであると思うのです。ですから、ユーザと一緒に分析・評価した結果を使って、みなさん考えてみてくださいというスタンスでいいと思っています。

とはいえ、多少の示唆的なアドバイスは持っていた方がいいに決まっています。それについては以前に「ボトムアップ戦略立案」という記事で書いているのでそれを読んでもらいたいのですが、ここでは多少補足的なこととおさらいを少しだけ書いてみます。

今までの議論で、ビジネスモデルの記述と分析を行い、自社のポジショニングを行いました。そのポジショニングから、強みをさらに生かす、別なところで生かす、弱みを改善する、ポジショニングを変えるといった方向にもっていく施策を考えるのが戦略でした。

ところが、時に陥りやすいワナに、そこで立案した戦略を金科玉条のように守らなければいけないんだということがある。これが大間違いなのである。戦略というのは、たまたまのそうした内外の環境だったから、あるいは、自分たちのもつ経営資源にそうした戦略に向いたものがあったからといったことでできあがったのである。

いわば、仮の、テンポラリーの計画でしかないのである。ということは、ビジネス環境が変わったときには当然のように戦略を変えていかなくてはいけないのだ。それができないとガラパゴス化と揶揄されてしまう。現代では、この環境の変化がものすごく激しいからいかに戦略の変化対応力があるのかと言うのが問われているわけです。

そのために、大事なのはここで議論していたようなビジネス（事業）モデルを絶えずチェックして、いつでも変えられるように見直すという作業が継続的になされるかということであろう。ということは、そこから展開される業務プロセス自体も戦略変化と同期して変えられる構造にしておかなければいけないのだ。

先日、このビジネスモデルフォーマットに従って、若い人たちにグループ討議をしてもらいながら、ユニクロのビジネスモデルを書いてもらった。ユニクロはちゃんと事業戦略も開示しているし、われわれも顧客として店に行ったりしておるので、何とか書ける。2グループに分けてやったのだが、それぞれで強み、弱み分析の結果が違ったりしておもしろかった。例えば、各年代層をターゲットにした品揃えや低価格商品、圧倒的な低コストサプライチェーン、上手なプロモーション、接客態度、確立したブランド力などいくつかの競争優位点が抽出された。

ところがそうしたユニクロでも今年の成績はあまり芳しいもではなく、販売実績も頭打ちに近くなっているそうだ。あれだけの勢いでデフレの元凶だなんて言われたのにどうなっているのだろうか。あるひとは、実用衣料なのかファッション性を売っているのかがあいまいだとか、ターゲット客層を全方位にしているのが限界だとか言っている。

そうなんですね、強みと思っていたものが弱みになることもあるのです。どれもいいことだけで固まった戦略はないということです。トレードオフで考えないといけなくて、またユニクロの例でいうと、いま郊外の大型店に力を入れているらしいが、その理由が多くの商品を置けるので欠品が減り、お客さんも選択肢が増えるからだそうだが、逆に言えば、在庫を持つということに他ならない。

ということで、繰り返しますが、戦略は生き物です。環境に合わせて変化させないとビジネスは衰退の憂き目に会うということです。ガラパゴス島のイグアナでさえ変化しているのだから。

＊この講座はまたこちらのブログに掲載することにしました。

ビジネスモデルからプロセスへ

さて、前回で「ビジネスモデルの記述と分析」が終わったわけですが、その次は「ビジネス要求とプロセスの特定」というフェーズになっていきます。これまでは事業がどんな構成要素から成り立っていて、そこの強みや弱みが何なのか、そして競合相手との比較で自分たちがどういう位置にいるのかを見てきたわけです。

そうした分析からはビジネス上でこうして欲しいというようなビジネス要求が出てきます。強みを更に強くしたいだとか他のところにも生かしたいとか、競争に勝つためにポジショニングを変えるとかいった戦略的なもの、あるいは弱いところを改善して守りを強化するといったことがそれにあたります。そうした要求に応えるためにそれを実現してくれるプロセスに展開していくわけです。

そのために最初に考えることは、ビジネスモデルとビジネスプロセスの関係を知ることです。それには、もう一度ビジネスモデルの構成を眺めることにします。ビジネスモデルは、どこの誰に、どんな商材を、どの経営資源を使って、どのように提供して、どうやって儲けるかでした。

これをもう少し業務的な見方で表現してみてください。すなわち、それぞれの構成要素の中ではどんな活動が行われているか、あるいは行われるべきかを吟味することです。そうすると、つぎのような活動が浮かび上がってくるでしょう。

どこの誰に　　　　　　　 ：顧客を獲得し、注文を受付ける
どんな商材を　　　　　 ：提供する商品とその仕様を決める
どの経営資源を使って ：使用リソースとその条件を決める
どのように提供して　　 ：商品を用意し、それを届ける
どうやって儲けるか　　 ：価格を決め、代金を回収する

いかがでしょうか。ビジネスの基本的な流れを表現していますよね。これは、業種・業態・規模に関係なくどんなビジネスも、いやビジネスではなくとも例えば何かイベントをやるとか、ボランティアでも同じです。

忘年会を行う場合でも、参加者を募って、どんな趣向にするかを決めて、会場や手伝ってくれる、挨拶してもらう人を決め、余興のアイテムを揃えます。そして、参加者に楽しんでもらい、会費をもらうわけです。これって同じですよね。

これが、ビジネスプロセスの基本構造ということになります。
　　　

ビジネスプロセス展開

前回は、ビジネスモデルから業務活動的な見方で変換してみるとどうやらプロセスっぽくなってきました。それを、ビジネスプロセスの基本構造を呼んで、これはどんなビジネスにも当てはまることを示しました。これをだんだんと具象化していきます。

まずは、そこから、○○プロセスという名をつけてみることをします。この名前の付け方はこれでなくてはいけないというわけではありません。まあ便宜上意味が通ればいいくらいでかまいません。むしろ、プロセスという名は付けない方がいいかもしれないくらいです。

というのは、これから、徐々に分解して詳細化していくわけですが、最初から○○プロセスに分解といったことをするとどうしても既成のものに影響されてしまうからです。しかし、いずれそうして分解した業務プロセスの親プロセスという風にせざるを得ないので仕方ないので付けておきましょう。

ここでは仮に、順番に「顧客接点プロセス」、「商品設計・開発プロセス」、「リソース提供・管理プロセス」、「バリューチェーンプロセス」、「収益プロセス」ということにしておきます。

顧客を獲得してから、商談を経て注文をもらうプロセスということで顧客接点プロセスです。ただ、この顧客接点プロセスという言い方には意味があって、お客さんから注文をもらうことだけではなく、既存顧客のアフターサービスのようなことも含んでいることを忘れないためでもあります。

商品設計・開発プロセスは、新規に商品開発するようなケースとオーダーを受けてから設計するようなケースもあります。特注品のようなときですね。ですから、一連の流れの外側の場合と、その流れに組み込まれている場合があります。

経営資源の管理は、そのリソースの種類によって様々ですが、基本は使用するリソースの“情報”を提供することと、そのリソース自体を管理することの二つの機能に分けて考えた方がよいでしょう。つまり、メインのプロセスを動かすときに参照したりするためのり―ソス状況を提供する機能とそうしたリソースに関する履歴、現状、計画の更新、削除および新規リソースの登録といった機能を指しています。

バリューチェーンは自社内でのサプライチェーンと会社間をまたがるビジネスチェーンがありますが、これらはまさにプロセスそのものですからイメージがわきやすいと思います。最後の、収益は設ける仕組みになりますが、プロセス的にはお金をどうやって請求して集めてくるかが主なところになります。これまでの議論をまとめたものが下図になります。

ビジネス要求とプロセス特定

だいぶ時間がたってしまったので、少しおさらいをしてみますが、まずはビジネスの要諦であるビジネスモデル、すなわち誰に何を提供して収益をあげるかというモデルを記述して、それの強み弱みや競合状況などの内外環境を分析しました。その結果、自分たちの置かれているポジションが明らかになってきます。

そうしたビジネスモデルの記述と分析が終わると、次にビジネスモデルに対応したビジネスプロセスの基本構造とプロセス名を書き出しました。そして、今度はビジネス要求とプロセス特定」というフェーズになります。

ビジネスモデルの分析で、新たな戦略や業務改善などといったビジネス要求が導出されます。それを実現するのは、プロセスですからそのプロセスがどれにあたるのかを検討します。そのために、ビジネスモデルとビジネスプロセスの対応付けを行ったわけです。そして、さらに業務プロセスへと絞り込んでいきますが、その手順は下記のようになります。

最初に、ビジネス要求を記述して、その要求が実現されるビジネスプロセスを特定します。新規顧客獲得が要求だったら、顧客接点プロセスになりますし、リードタイムの短縮であれば、バリューチェーンになります。販売代理店の強化戦略だったら流通チャネルの管理プロセスだったりするわけです。

そうして特定されたビジネスプロセスはまだ大きな括りですから、それを分解して、より小さな単位の業務プロセスに落とし込む必要があります。この業務プロセスへの分解については、このあとのエントリーで詳述していきますが、あらかじめ分解された業務プロセスを持っておいた方がよいでしょう。

こうして抽出された候補の中からビジネス要求を実現すべき対象としての該当プロセスを特定することになります。
　　

業務プロセスへの分解の考え方

前回は、ビジネス要求を埋め込むべき業務プロセスの特定という手順を説明しましたが、それにはビジネスプロセスから業務プロセスへの分解を行う必要があるわけで、それについて検討していきましょう。

前々回ビジネスモデルから「顧客接点プロセス」、「商品設計・開発プロセス」、「リソース提供・管理プロセス」、「バリューチェーンプロセス」、「収益プロセス」というプロセスに展開しました。この段階でのプロセスは大きな括りのものになっていますので、それらを分解していきます。

そのとき、注意しなくてはいけないのが、すぐに○○プロセスというふうに考えないことです。それをすると、既存にそういったプロセス名を冠したソフトウエアなどがあるため、それに影響されてしまい、ビジネス視点からシステム視点へシフトしてしまう恐れがあるからです。

ですから、まずはビジネスプロセスにある基本構造であるそれぞれの要素についてその中身を吟味することから始めます。その要素が持つ機能はいったい何をすることなのかとか、どんなことができればいいのかといったことを考えるわけです。

つまり最初の「顧客接点プロセス」は「顧客を獲得し、注文を受付ける」ということですから、この中身はいったいどんなことだろうかと考えます。顧客を獲得するといっても顧客の種類、性格によっても違ってきます。新規なのか既存なのか、既存でもリピート客なのかそうではないのかでその獲得の仕方が変わってきます。

新規顧客だと、何もしないで注文が来るわけではないので、注文をもらうためには、まずは商品を知ってもらうことをしなくてはいけないと思うはずです。商品を認知してもらうためのプロセスが要ることがわかります。それを「商品認知プロセス」と名付けるとひとつの業務プロセスが出来ることになります。

あとでは、「商品設計・開発プロセス」や「バリューチェーンプロセス」、「収益プロセス」といったものは、比較的分解しやすくイメージがわきやすいと思いますが、「リソース提供・管理プロセス」をどう扱ったらいいのか悩むと思います。

前回、経営資源の管理は、リソースの“情報”を提供することと、そのリソース自体を管理することの二つの機能に分けて考えた方がよいと言いました。そのうちいろいろなパターンがあるのが、リソース自体の管理です。もう一度、リソースとは何だったかをみると、ヒト、モノ、カネ、技術、ブランド、チャネルといったものでした。

ヒトだと、広い意味では人事システム全体が該当してきますが、ここではビジネス実行に直接関係するような機能に絞りましょう。従って、給与、福利厚生などは外した方がよいでしょう。そうなるとメインは人材管理であるとうことがわかります。

モノでは、設備の管理が主体になります。サプライチェーンを実行するために、ビジネスに必要な設備や装置を買ってくるとか、設備のメンテナンスなどを行うといったプロセスがそれに該当してきます。

このようにビジネス実行のために、それぞれのリソースが準備されているという状態を作っておくことが管理という意味で、それが重要な機能なのです。そしてそれをどう使うかを判断するためにその状態を「情報」という形でいつでも提供しなくてはいけないのです。
　　

業務プロセスにはどんなものがあるのか

ここでは、具体的にどんな業務プロセスがあるのかを見ていきましょう。前回ビジネスプロセスから業務プロセスへの分解の考え方を議論しました。ビジネスモデルの構成要素とビジネスプロセスを実行するためには、どんなことをするさらに細かいプロセスが必要なのかという見方で分解していきました。

ここで注意しなくてはいけないのは、ビジネスモデルを作るためのプロセスではないということで、繰り返しますが、ビジネスモデルを実行するための受け皿となる業務プロセスの抽出ということです。そうした観点の分析で浮かび上がったものを挙げてみます。

１．顧客接点プロセス
顧客獲得プロセス／商談・営業プロセス／契約プロセス／顧客囲い込みプロセス／保守サービスなど

２．商品開発・デザインプロセス
調査・研究プロセス／新規商品開発プロセス／商品設計プロセスなど

３．リソース提供・管理プロセス
採用プロセス／人材管理／設備管理／保全プロセス／資機材調達プロセス／資金調達管理プロセス／知的財産・特許管理プロセス／ブランド管理プロセス／サプライヤ・販売代理店管理プロセスなど

４．ビジネスチェーンプロセス
生産計画プロセス／調達プロセス／生産出荷プロセスなど

５．収益プロセス
代金請求・回収プロセス／価格決定プロセスなど

とりあえずこんなところになります。これでもまだ抽象的なので実際にはもう少し詳細化する必要がありますが、ここまでくれば、そこをあまり突っ込むのではなく、プロセスの構造の方に向かった方がいいと思います。

ここをいくら詳細化したところで参照モデルを作ることになってしまいます。目的はそこではありませんので、業務プロセスがもつべきだいたいの必要機能を網羅していればいいと思います。こんなプロセス機能があればビジネスモデルが実行できるなということがわかればよいと思います。
　　

業務プロセス構造化

前回のエントリーで、ビジネスプロセスを分解して業務プロセスを洗い出すことを行いました。つぎは、そうした業務プロセスの構造化を行います。構造化とはいったいどういうことなのでしょうか。私は以前次のように定義しています。

（１） 全体を俯瞰した上で、構成要素に分解し
（２） それら構成要素間の関係を分かりやすく整理し
（３） 統合化されたモデルを作ること

これを思い出してほしいのですが、すでにビジネスモデルを考えたときにも同じようなことをやったのを覚えていますか。業務プロセスレベルでも同様の考えかたで構造化してみましょう。すなわち、業務プロセスというのはどういう構成要素から成り立ってその関係はどうなっているのかをみていくことです。

プロセスというものの特徴の一つは時間の要素を含んでいることがあります。ということは、始まりと終わりがあるということです。何で始まって何で終わるのかがプロセスを規定するうえでかなり大事なことになってきます。つまり、プロセスの始点と終点を定義することが構造化作業の最初になります。

そうなると、始点が先か、終点が先かといった議論になりそうですが、そこはこのあとのプロセス設計で詰めていきますので、ここでは構造上の出発点と終わりって何なのだろうかと考えることをします。

そして、それが決まると次は、この始点と終点の間に何があるのか、そういうものをどう配置すればいいのかになるわけです。プロセスが始まると何かのアクティビティを繰り返して、終点に行き着くという流れができるわけです。ここでアクティビティという表現をしましたが、タスクでもいいかもしれません。あまり言葉に拘泥しないでもいいと思っています。要は、中身がどんなものをいうかをきちんと定義できるかになります。

ここでも注意したいのは、普通の言葉で考えることです。ひょっとすると、「プロセスの始点はイベントドリブンだから、そのイベントはシステムのどこのアウトプットからきて・・・」なんて言わないで、仕事で会話している時に使っている言い方でかまいませんので無理をしないでください。

ただ、いきなり一般化された言葉で構造表現をするのは大変難しいので、何か例をもってきて帰納的なアプローチが有効かもしれません。例えば、身近なものとしてレストランで食事の注文に対して調理して出すなんてプロセスを考えてみるといったことです。

ということで、ここが構造化の最初の骨格作りになりますが、まだ個別概念でとどまっていますのでそこから抽象化、一般化していきます。