吉原賢治　Ｎｉｘシステム研究所　代表[keyperson]：ロジスティクス・ビジネス[LOGI-BIZ]バックナンバー

2006年3号

*下記はPDFよりテキストを抽出したデータです。閲覧はPDFをご覧下さい。

MARCH 2006 2 かけ声に終わったＢＰＲ ――ビジネスモデルは、どのように構築し、どうマネジメントすれば良いのでしょうか。
「方法論はありません。
そのためにＢＰＲ（ビジネス・プロセス・リエンジニアリング）も掛け声倒れに終わってしまったのだと思います。
日本でも九〇年代前半にはマイケル・ハマーのＢＰＲが、それこそ救世主のように扱われて、一大ブームになりましたが、結局は現状否定と理念の追求に終止してしまいました。
ＢＰＲにエンジニアリングと呼べるほどの方法論の無かったことが、その主な原因でしょう」「エンジニアリングと呼ぶからには、一定の手順を示す必要があります。
そして成果物の再利用が確保されなければなりません。
共用可能な構成部品を蓄積して、一つの製品としての基本構造を持った完成モデルのフレームワークが存在しなければならない。
この完成モデルに当たるものがビジネスモデルあるいはビジネス・プロセス・モデルであるとすると、ＢＰＲアプローチの線上にはそれは存在しない。
ビジネスモデルの発明への夢と期待が、ただ形骸のようにあるだけです」 ――ＢＰＲアプローチとは？「従来のプロセスを白紙にして、ゼロベースであるべき姿を考えるというアプローチです。
これはＩＥ（インダストリアル・エンジニアリング）の大家とされるナドラーの『理想システム』と同じです。
確かに全くゼロから事業を始める場合であれば有効なアプローチなのでしょう。
しかし、それ以外の場合、つまりほとんどの会社では、いくら理想的なプロセスを考案したとしても、まず現状のプロセスがあります。
それをベースにして理想に向けて改革していかなくてはならない。
その方法論や手順が示されていない」 ――しかし、成功事例があったからこそＢＰＲがブームになったのでは？「上手くいった事例があったとしても、それは優れた個人が閃きを発揮させて発明したものであって再現性はありません。
方法論がないというのは、地図のない状態で近道を探り当てるようなものです。
そうした洞察力に優れた人も、中にはいるでしょう。
しかし優れた個人による発明が常に成功するとは限りません。
そのナレッジを皆で共有することもできない」「そのために、成功したとされるＢＰＲでも改革は一過性のもので終わってしまっている。
改革後にプロセスを管理する立場になった人は、なぜそのようなプロセスになっているのか全く分からないのだから当然です。
しかも、ＢＰＲで改革の対象となったのはプロセス全体ではなく、一部分に過ぎませんでした」「私から見ると、ＢＰＲという言葉は広く普及したものの、実際にプロセス管理を行っていると言える企業はほとんどありません。
それどころか自分の会社の業務プロセスの現状さえきちんと把握できていないのが多くの会社の実態ではないでしょうか」 ――何から手を付けるべきですか。
「ビジネスプロセスが整理されていないと標準化も改革もできませんので、まず現状の業務を示すプロセスマップを作る必要があります。
それに対して業務プロセスの『to be （あるべき姿）』を設計し、現状のプロセスを改革する。
その結果、新しい『as is （現状）』のプロセスが出来上がる。
それをまた検証して改革する。
これを繰り返していくことがビジネス・プロセス・マネジメント（ＢＰＭ）の実務です。
ところがほとんどの企業が最初のプロセスマップを作る段階でバンザイしてしまっている」吉原賢治　�
裡蕋�轡好謄犖Φ羹蝓∥緝� 「ＢＰＲはエンジニアリングとは呼べない」サプライチェーンのあるべき姿を描くだけでは何も実現しない。
あるべき姿は方向性を示しているに過ぎない。
改革の実行には、現状の業務プロセスを表記する方法と、それを改造する手順が必要だ。
これまでＳＣＭには、そこが抜け落ちていた。
（聞き手・大矢昌浩） THEME 3 MARCH 2006 KEYPERSON ――プロセスマップというのは？「現在のビジネスは、いくつものトンネルを通過する鉄道のように、コンピュータと人間の仕事が交互につながる形でできあがっています。
コンピュータのアウトプットが人間のインプットになり、人間の意思決定というアウトプットがまたコンピュータにインプットされる。
その流れは企業をまたがり、そして循環しています。
企業の外に出て顧客に届き、また戻ってくる。
こうした人間の意思決定やコンピュータの処理が連なっている全体の流れを可視化したものがプロセスマップです」「プロセスマップを作ることで、それぞれの担当者だけではなく、誰でも全体のプロセスが分かるようになります。
そして、そのプロセスを検証し改革する。
それがＢＰＭです。
これまでも部分的にはプロセスを記述して分析してきましたが、そのやり方や書き方が人によってまちまちで、他人が見ても分からなかった。
電気の配線図や建築図面と同様に、誰が見ても分かるプロセスマップにするには基準が必要です」 ――その基準が存在しないのでは？「ビジネスプロセスのモデリング手法はこれまでもいくつか発表されてきました。
七〇年代の初頭に米国国防総省が採用した『ＩＤＥＦＯ（ Integration Definition for Function Modeling ）』もその一つです。
八〇年代には独ＳＡＰ社の依託によって独 IDS Scheer 社が『ＡＲＩＳ（ Architecture of Integrated Information System ）』を開発しています。
ＳＡＰ社がプロセスモデリング・アーキテクチャに適用しているものです」「いずれの記述方式も、それぞれ使い道はあります。
しかしそこには、プロセスを分解する表記法とプロセス属性情報を整理する体系が用意されているだけで、ビジネスモデルの階層を分解し、組み立てる体系は用意されていません。
そのためＢＰＭ、つまりビジネスプロセスそのものの分析や設計には向かない」「『ＵＭＬ（ Unified Modeling Language：統一モデリング言語）』は一歩進んだ表記方式ですが、ＩＴの専門家以外にはなかなか使いこなせない。
そしてこれにもプロセスモデル設計のための階層分解方式、つまり製品部材の階層組立構造（ＢＯＭ）は存在しません」「表記方式としては、今後は誰にも読み書きできる『ＢＰＭＮ（Business Process Modeling Notation ）』に、一本化されていくのでしょうが、それも表記形式の体系化の域にとどまっていて、エンジニアリングの方法論には成り得ません」プロセス記述方式の限界 ――米サプライチェーン・カウンシル（ＳＣＣ）の提唱する「ＳＣＯＲ（ Supply Chain Operations Reference model ）」はどうですか。
「九八年にアメリカのニューオリンズでＳＣＣの第２回カンファレンスが開催されて、そこで初めてＳＣＯＲを知りました。
当初はいたく感動しました。
というのもＳＣＯＲが三階層のプロセス分解構造を持っていたからです。
しかし、その後のスタディで、ＳＣＯＲには、マテリアルプロセスやヒューマンプロセスを含むロジスティクスプロセスが捨象されていることを知りました。
それではビジネスモデルにはならない」「しかもＳＣＯＲはアプリケーションパッケージのベンダーやエンドユーザーのためのマクロなリファレンスモデルであって、ビジネスモデルの設計にしろ、サプライチェーンの設計にしろ、設計のための技法を内蔵したものではない。
そんなことから、ＳＣＯＲの最大の機能は十三種のメトリクスを使ったベンチマーキングにあると割り切ったほうがいいと考えるようになりました」 ――吉原さんご自身は九五年に出版した「情報型ロジスティクス構築論」（ＮＴＴ出版）で、三階層のロジスティクスプロセス設計モデリング手法として「ＡＬＯＷ ―ＬＳＰ」を発表していますね。
「ＡＬＯＷ ―ＬＳＰは、企業間をまたいだプロセスモデリングを行うための手法です。
基本となる一〇個のプロセスコンポーネントを設定してあり、それぞれにベストプラクティスやコモンプラクティスを組み込んであります。
その組み合わせでロジスティクスプロセスのネットワーク・デザインを行うわけです。
こうして設計したロジスティクスモデルを補給連鎖システム設計と呼びました」「しかし、これもモデルとしては不完全でした。
サプライチェーンのマクロ設計の域を出るものではなかった。
そこで、私も本来であれば引退するような年なのですが（笑）、その後も私個人のライフワークの終着駅として密かにサプライチェーンのモデリング手法の開発に取り組んできました。
その目的は、大げさに言えば世界初のビジネスモデル・ライフサイクル・エンジニアリングの実現です。
既に三つの企業に対する導入も済ませ、ようやく完成しましたので、近く発表するつもりです」