事例で学ぶビジネスモデリング（6）
ビジネスモデリングの使いどころ
〜IT技術者のための戦略・業務分析入門〜

ウルシステムズ
シニアコンサルタント 村上歴
2006/1/27

1｜2｜3｜次のページ

---

　第5回「モデリングだけでは語れない業務分析の現場」では、小売業の販売計画業務を分析し、あるべき姿を描く事例について実際のプロジェクトでの進め方を説明した。今回は、流通業の企業間取引の流れを分析し、業務効率化のためのシステム像を描くためにビジネスモデリングを活用した事例を紹介する。

　なお、この事例は、弊社の複数の事例を基にした架空のものであることをあらかじめお断りしておく。

◆ 1. プロジェクト開始まで

◇ 1-1. 顧客からの依頼

　 夏の暑さも過ぎ去ろうとする9月の午後、筆者は長年お付き合いのある大手食品卸C社を訪問していた。システム部長であるM氏から、相談に乗ってほしいとの連絡があり、話を聞きにやって来たのである。C社の本社ビルは、物流センターが立ち並ぶ臨港地区にある。受付を済ませ、センターを出入りするトラックを見下ろせる部屋で待っていると、M氏が相変わらずの笑顔で現れた。商売を営む職業柄か、M氏はあいさつや笑顔が気持ちいいのが印象的で、会議室も自然と和んでくる。そんなM氏だが、いざというときには社内外どちらに対しても厳しく、かつ適切な対応が取れる人であり、C社のITを背負っているという責任感を強く持った人でもある。

　M氏はいつものように明るい声で話を切り出した。

M氏　早速ですが、本日お呼び立てしたのは、新しい受発注システムをどうするかについてご相談したかったからです。ご存じとは思いますが、この業界も大手が系列の中小を吸収合併するなど再編の動きが激しくなっていて、弊社としても競争力を高めるため、サービスレベルの向上と取扱商品の拡大を計画しています。システム部門でも、これに対応するため受発注システムを再検討しているところなんですよ。

筆者　なるほど。卸さんの受発注システムの場合、ポイントになるのは、やはり手間が掛かる仕入れ先・得意先別の個別対応の部分でしょうか？

M氏　そうですね。仕入れ先・得意先ごとに業務やシステムがいろいろ違っていて（*1）、1つ1つへの対応は難しくはないのですが、弊社全体として見ると業務・システムともにかなり複雑になってしまっています。個別のいろいろな決定事項や慣習が担当者の頭の中にしかないことも多く、特にシステムを維持していくための負担が大きくなっています。これを解決しなければ、この拡大計画に対応することは不可能になってしまいます。

（*1） ITコンサルタントのホンネ（その1）

「いろいろ違う」は、よく出てくるキーワードだが、中身を具体的に確認してみると、意外にそれほど違わないことが分かったりする。実際に業務を担当する立場ではもちろん異なることをやっているのだが、第三者的な立場で見ると、「ここが違うだけ」というようにとらえられることも多い。もちろん本当に複雑であることも少なくなく、いずれにせよその全貌をつかむのにはかなり時間がかかる。

　M氏の話を総合すると、以下のようになる。

◇ 1-2. 現状の課題

　食品卸売業の仕事は、乱暴にいってしまうと、メーカーから仕入れた商品を、得意先である小売業に販売・配送することである。食品卸であるC社の得意先は、総合スーパー、食品スーパー、コンビニエンスストアなどさまざまであり、そこからの発注を日々受け付け、受注した商品を日々得意先の物流センターや店舗まで配送する。そして、おおよそ月次に行われる締めに合わせて請求や支払い内容の確認を行う。また、新しい商品の取り扱いを始めれば、その商品の情報も提供する。

図1 C社を取り巻く流通業界のプレーヤー（一部）と、その間の情報交換（クリックすると拡大）

　このような基本的な業務の流れはどの得意先に対してでも変わらない。複雑なのは、これら1つ1つのやり方が得意先ごとに少しずつ違うところなのである。

　例えば、ある得意先はFAXで発注を行ってくる。ほかのところはEDIで送ってくる。EDIで送ってくるところについても、得意先の独自方式に合わせなければならない場合もあれば、VAN会社が提供するシステムの仕様で通信するため、その仕様に対応したシステムを購入して対応する場合もある。

　このような「個別対応」は通信のやり方だけではない。ある小売業が「発注」といって送ってくる情報と、別の小売業が送ってくる「発注」は意味が異なる場合がある。すなわち、一方は「これで確定」という意味であり、もう一方は「予定（後から修正する）」であったりする。前者であれば受け取ってすぐに出荷の準備を始められるが、後者は決められた締め時刻までは準備を始めることができない。締め時刻を過ぎた後で変更が来ることも珍しくない。

　このように、やりとりの方法・訂正ルール・用語の意味などの個別対応がC社の得意先ごとに発生している。個々の対応はそれほど負担ではないのだが、得意先の数が何千、何万社と非常に多いため、全体として見ると個別対応のシステム投資負担が非常に大きなものになっているのである。

　メーカーとの間ではこのような情報交換はかなり標準化が進んでおり、仕入れ先ごとにではなく「業界ごと」に標準のやり方が存在するため、得意先（小売）に対する対応に比べてそれほど負担が大きくはない。

　このような状況を抜本的に解決するには、1社だけの努力ではどうにもならない。業界として一定のコンセンサスの下に標準化を進めていく必要があり、このような活動はこれまでもずっと行われてきた。ただし、データの内容についての標準化は進められていたが、先ほどの「発注」の違いのようなデータの解釈の仕方、取り扱い方については、標準が確立されておらず、これまで手付かずだったのである。

　M氏は、今回の機会に自社のシステムを刷新するだけではなく、その成果を卸売業界の中での標準的な仕組みとして提案することも考えているという。そして、そこに積極的にC社がかかわることでその存在感をアピールすることも計算に入れている、と語った。

◇ 1-3. 課題に対するアプローチ

　このような課題はどのように解決すればよいだろうか。

　システム開発の場合には「開発プロセス」という考え方があり、要件定義・設計・実装・テストの流れに沿って進めていけば、基本的にはプロジェクトを円滑に進行させることができる。また、ある意味でシステムが無事に稼働すること、というプロジェクトのゴールは明確である。

　今回のようなプロジェクトでは、終わった後何が達成されていればよいのか、というゴールが漠然としていることがほとんどである。そのため、プロジェクトの中で何の作業をどのように進めるかは、与えられた課題や顧客の状況によって大きく変わる。この点がシステム開発プロジェクトと大きく異なるところである。そして、我々コンサルタントにとっては最も面白く、また苦しめられるところでもある。

　このようなプロジェクトを進めるに当たっては、この連載の第3回、第4回で説明したような、コンサルティングのフレームワークを用いて道筋を立てることが多い。

　まず第3回「戦略コンサルの基本『仮説検証プロセス』」で説明した仮説検証型プロセスについておさらいしておこう。まず、顧客との何回かのディスカッションを通じて、問題の原因についての「仮説」を立てる。そしてインタビューや各種の経営情報の調査を行い、その仮説を検証しながら、課題をさらに整理し、この課題に対して現状を改善するための打ち手を立案する、というものだ。

　第4回「企業の健康を診断する『業務分析』」で説明したものは、課題分析型プロセスである。顧客からの現状詳細ヒアリングを通じて、現状の課題を収集し、それらの根本原因を特定することで、課題に対する最も効果的な打ち手を見つけ出す。ただし、課題分析型であっても、手ぶらでヒアリングを始めると、回を重ねるごとに話が大きくなっていき、プロジェクトの作業が膨大になりやすいため、何らかの仮説を持ちつつ、それを確認する形で現状調査を行うのが効果的である。

図2 コンサルティングプロジェクトのフレームワーク例

　コンサルティングプロジェクトにおいては、このようなフレームワークの中から状況に最も適したものを選択する必要がある。

　ここで極めて重要になるのが、ゴールの見通しを立てることである。特に、どの程度の仮説をどの時点で立てられそうか。現状調査や課題はどれくらい収集すればよいのか。成果物の具体的な内容や表記法はどのようなものか。問題解決の主要なロジックはどのようなものか。これらをうまくつなげていくシナリオ、いわば「筋」が見えているかどうかでプロジェクトの成否は大きく異なる。難しいといわれるプロジェクトで、うまく「筋」を見いだせるかどうかがコンサルタントの腕の見せどころでもある。

　さて、今回解決すべき問題は、「卸売業においての、加工食品の受発注／物流／決済情報の交換における個別対応の解消」である。今回のプロジェクトで見るべき「筋」は、（1）どうやって「個別対応」を客観的に表現するか、（2）個別対応の負担を改善する方法を見つけられるか、（3）その改善方法をシステム化できるか、の3点である。正直にいうと、筆者は（1）（3）についてはそこそこの自信があったものの、（2）には不安があった。しかし、この点については社内の流通業に詳しいメンバーとディスカッションを通じていくつかのヒントをもらったことで、ある程度の現状分析を行えば最終形が見えてくるだろうという確信を持てるようになった。

　最終的に、前述の2つのフレームワークを組み合わせて、次のようなプロジェクトの進め方に決めた。

　最初に個別対応についての現状確認のヒアリング調査を行い、1つ1つの「個別ビジネスプロセス」の状況を明らかにする。次に、仮説としてそれらをすべて統合した「統一ビジネスプロセスモデル」を描く。続いて、それを用いて個別ビジネスプロセスが表現できるかどうかを検証する。最後に、システムがこの統一モデルに従った情報交換を実行できるように、モデルを表現する際の仕様を設計する。

　このようにして、期間は3カ月間、3名でのプロジェクトが立ち上がった。プロジェクト規模としては、小と中の中間辺り、といった程度である。

1/3

INDEX
事例で学ぶビジネスモデリング（6） ビジネスモデリングの使いどころ
	Page1 ◆ 1. プロジェクト開始まで
	Page2 ◆2. プロジェクト作業内容
	Page3 ◆3. エピローグ（業務の全体像を把握することの重要性）

IT Architect 連載記事一覧