日本市場とＳＣＯＲモデル

＝日本市場にとってＳＣＯＲモデルは如何に有効か＝

１９９９年７月
ＥＲＰ研究推進フォーラム主幹研究員　梅澤伊憲
（季刊「ＳＣＭリサーチレビュー」編集長、 �褐o営資源システム研究所 取締役研究開発部長）

本稿は、ＥＲＰフォーラムＳＣＭ研究プロジェクト（当時）の機関誌として発刊した「ＳＣＭリサーチレビュー」誌第４号の特集「’９９サブライチェーンワールド参加報告」に寄稿したものに、加筆・改訂したものである。＜図表の掲載はもう暫くお待ちください＞

はじめに

  ‘９９年４月に開催されたサプライチェーン ワールド（サプライチェーン協議会^（註１）［略称：ＳＣＣ］の世界大会）に引き続いて実施されたＳＣＯＲ^（註２） Workshop^（註３）に参加した。これは、ＳＣＣが昨年末から力を入れて企画し繰り返して実施を始めた、ＳＣＯＲのより深い理解と実践的な活用方法をサプライチェーン マネジメントのプラクティショナー（実践者）たらんとする人達にトレーニングする場である。このシカゴのワークショップでは、特に２０余名を数えた日本人受講者向けの特別のセッション（プログラムやテキストは隣室で行われた英語版セッションと共通）が編成され、ＳＣＣのChief Technology OfficerであるScott Stephens氏自らの解り易く熱のこもった講義と、参加者の熱心な姿勢が相俟って、今ＳＣＣ大会参加の締めくくりとしてのワークショップを意義のあるものにする事ができた。
　 私（梅澤）は、昨年度１年間の第一次“ＳＣＭ研究プロジェクト”および今４月からの第二次“ＳＣＭ研究プロジェクト”を通して「“サプライチェーン マネジメント”に焦点を当てた日本市場のビジネスプロセス変革の在り方」を模索してきた。その中でも「企業間にまたがるビジネスプロセスの変革およびそれを支援すべき方法論と情報技術」を何とか体系化して、日本の市場を構成する企業群の２１世紀に向けた幅広い取り組みの求心力が形成出来ることを期待している。
　本論では、昨年のＳＣＣニューオルリンズ大会から今シカゴ大会参加に至るＳＣＣ関連の動向と、結果として得られたＳＣＯＲの理解と評価を中心にして、日本市場および日本企業がビジネスプロセスエンジニアリングの視点から“ＳＣＯＲ”をどのように捉えたら良いのか、また今後の課題は何かについて報告する。大会そのものの報告はＳＣＣおよび日本支部によって順次なされており、またＳＣＯＲ Workshopの内容はＳＣＣのメンバーシップに抵触する部分が多く一般公開は出来ない事などから、夫々割愛した。

◆註１ サプライチェーン協議会［ＳＣＣ：Supply Chain Council］：米国の、サプライチェーンマネジメントの研究と向上を目的とし、ＳＣＯＲモデルの開発、展開推進を中心とする活動を続ける民間の非営利団体。‘９７年から協議会の運営管理体制を確立し、現在参加企業数は世界各国の５００社余り、ドイツ等の欧州各国、日本等のアジア各国に支部機構を形成するに至っている。ＥＲＰ研究推進フォーラムは、ＳＣＯＲの利用研究とサプライチェーンマネジメントへの協働を目的として昨年ＳＣＣメンバーになっており、日本支部のボードメンバーでもある
　参照：www.supply-chain.org

◆註２ ＳＣＯＲ：Supply Chain Operations Reference model。ＳＣＣが開発維持し、ＳＣＣのメンバーシップの下で使用が公開されている、グローバルなサプライチェーンの記述、性能測定、評価のための、ビジネスプロセスの標準階層および関係の定義、記法、用語の定義等の総称

◆註３ ＳＣＯＲ Workshop：ＳＣＣが主催するＳＣＯＲ利用のトレーニングを目的とするワークショップ。ＳＣＯＲの実用に関するトレーニングなのでＳＣＯＲの利用権を持っている事が必要。従って参加資格はＳＣＣメンバーにかぎられる

１．ＳＣＯＲモデルとは

（１）日本への紹介経緯
 ‘９６年のＥＲＰ研究推進フォーラム発足当初から、一層の機能統合化の過程にあったＥＲＰシステムを理解し日本市場へのより良い導入を検討する上で、前提とすべき基本的な企業モデル、特にビジネスプロセスモデルの理解が必要な事が課題となっていた。これまでにも数多くのビジネスモデルの紹介や研究がなされている。フォーラム活動過程でも以下のモデルを改めて勉強してきた。

・ＡＰＱＣ：Business Process Classification^{（註１-１）}
・ＡＲＴＳデータモデル^{（註１-２）}
・ＯＡＧＩＳ：ＯＡＧIntegration Specification ^{（註１-３）}
・ＯＭＧ Common Business Object^{（註１-４、１-５）}

これらは残念な事に全て「日本発」ではない。また、日本の企業や業界にも数多くの“企業モデル”、“業務モデル”と呼ぶべき記述や成果物があるが、企業（業界）内の共通理解に止まっており、グローバルな標準に向けた一般化や抽象化がなされていないものばかりである。これは「日本発」のソフトウェア技術やアプリケーションパッケージが世界に通用するものにならない事と密接に関係している。また海外から紹介されるモデルも、日本語による再定義が必要な事や、ベースの企業運営実態に日米間でかなりの乖離があると思われている事、モデルを使って評価しようとするパッケージソフトウェアのモデル表現ともかけはなれている場合が多い事等から、結局、実業務の表記にも使えずソフトウェア機能の評価にも使えない事になってしまっている。
　そのような中で注目されたのが、当時はＰＲＴＭ社（Pittglio Rabin Todd & McGrath Inc.）中心で運営されていたサプライチェーン協議会が検討していたＳＣＯＲモデル^（註1-6）である。
・企業内に閉じたモデルではなくサプライチェーンという企業間のプロセス連鎖を対象とするものである事
＜従って、以下の特徴を持っている＞
・徒に企業のプロセス全域を対象にするのではなく製品やサービスの供給プロセス連鎖にフォーカスしており、サポートプロセス（間接業務）と明確に位置付けを分けている事
・特定の業種モデルから業種を超えた抽象化、汎用化を目指している事
・グローバルな標準として機能できないと国や地域をまたがるサプライチェーンに適用できなくなるので必然的に国際的な活動に展開していく事
等が分り、このモデルの発展性・将来性が強く感じられた。
　その後、９７年夏のＳＣＣの第三者団体としての独立や日本支部設立への側面支援等を通して関係を継続してきており、当フォーラムもＳＣＣのメンバーとしても登録し活動している。フォーラム内外９８年の春期大会^{（註１-６）}および今年４月の“サプライチェーン ワールド”^{（註１-７）}へも継続参加している。

◆【註１-１】 Process Classification Framework：米国ＡＰＱＣ（American Productivity and Quality Center）が開発したビジネスプロセスをベンチマーキングするための標準定義。４乃至５階層からなるプロセスの定義と、それらの機能、性能を評価する評価基準からなる。これが発展して米国商務省のマルコムボルドリッジ賞の選定基準となっている。日本でも経営品質賞選考時のプロセス評価基準となっており、ＪＰＣ−ＳＥＤ（社会経済生産性本部）が中心となってベンチマーキングの研究を進めている。ＡＰＱＣは、ＩＢＣ（International Benchmarking Clearinghouse）を作り、東南アジアを含む各国企業のベンチマーキングの推進に当たっている
　参考：www.apqc.org

◆【註１-２】 小売業データモデル標準化推進国際機関であるＡＲＴＳ（the Association for ReTail Standard）が制定したアプリケーションインディペンデントな小売業共通のデータモデル。1997.May「平成８年度 商取引モデルに関する調査研究報告書」(社)日本機械工業連合会、(財)流通システム開発センター発行

◆【註１-３】ＥＲＰパッケージソリューションベンダーが、ＯＡＧ（Open Application Group）活動を通して異機能パッケージ間接続を目的としてトランザクションの種類とフォーマットを標準定義している。当初は、単なるアプリケーションインターフェイスの標準化だけではなくアプリケーションモジュールのモデル定義を目指していたが、現実にはインターフェイスデータ標準の制定維持が中心の活動になっている。最近はＳＣＣ活動との同期を図ろうとしている。
　参考：www.openapplications.org

◆【註１-４】 ＯＭＧ（Object Management Group）が、ＣＯＲＢＡ層の標準をバックボーンとして分散オブジェクトが実装すべきアプリケーションモジュールの標準仕様作りを始めた。昨年来数次にわたり実装オブジェクト要求仕様（ＲＦＰ）の形で世界中のオブジェクトベンダーに提示された。ＥＲＰ（ＭＲＰの発展形と捉えている）を含むアプリケーションコンポーネントの定義とコンポーネント間のインターコネクティビティ（相互接続性）を３種類のパターン毎に設定している。（ＲＦＰ仕様書参照）
　参考：www.omg.org

◆【註１-５】 国内では、ＯＭＧの支部的なボランティア団体であるＪ−ＳＩＧ、分散オブジェクト協議会、ビジネスオブジェクト推進協議会（ＣＢＯＰ）等が発足して夫々の観点から活動を始めている。中でもＣＢＯＰのビジネスオブジェクトコンポーネント化の動きは今年初めにＯＭＧとの提携関係も出来、グローバルなオブジェクトモデルへの参画が期待される。本誌Vol.3（1999.May）「特集１ 進化する情報技術とＳＣＭ」「§４．ビジネスオブジェクト標準化と企業間連携（ＣＢＯＰ専務理事 堀内一）」参照

◆【註１-６】 ＳＣＯＲ（Supply Chain Operations Reference model：サプライチェーン運営参照モデル）。当初は、ＰＲＴＭ社のハイテク製造業を中心とする多年のコンサルテーションの蓄積をベースとしたものだった。‘９７年にＳＣＣ（Supply Chain Council：サプライチェーン協議会）が団体としての体をなすに至り、オープンな標準モデルとして衣替えをしてグローバルな適用を推進している。ＳＣＣの中にＴＣ（Technical Committee）とPLAN、SOURCE、MAKE、DELIVERの４分科会が設けられており、参加企業有志によって継続的にＳＣＯＲのレベルアップ・改訂作業を行っている。今年にかけて、物的供給だけでなく“サービス供給プロセスの折り込み”、“リバースロジスティクスへの対応”、ＥＴＯ（注文設計）対応の“設計プロセスの折り込み”等が検討されている。現在は第3.1版であり、９月には第4版への改訂が予定されている。
　参考：www.supply-chain.org

◆【註１-６】 本誌Vol.0「特集 サプライチェーン協議会（ＵＳ）‘９８年春期大会 参加報告」参照。

◆【註１-７】 本誌今号（Vol.4）「特集２．サプライチェーンワールド参加報告集」参照

 （２）ＳＣＯＲとは
　昨年度のＳＣＭ研究プロジェクトのＳＣＯＲ研究ＷＧ（ワーキンググループ）活動で、ＳＣＯＲモデルの日本語訳と若干の分析を試みた。また、プロジェクト主催のセミナーにＰＲＴＭのコンサルタントや実践企業の方々を招聘したり、ＳＣＣ大会に参加したりする事で、ＳＣＯＲの概論^{（註２-１、２-２）}や適用事例に触れる事ができた。
　更に、昨年末にＳＣＣによるＳＣＯＲワークショップの試行版を東京で開催し、掲記のシカゴでのワークショップにも参加した^{（註２-３、２-４）}。特にシカゴでのワークショップはＳＣＣチーフテクノロジーオフィサーのスコットスティーブンス自らの講義であり、プログラムも昨年末時点に比べるとかなり完成度が高くなっており、ＳＣＯＲのモデルおよび方法論としての評価ができるようになってきた。
　これらを経営指標としての評価やビジネスエンジニアリングの視点からまとめた研究論文がプロジェクト初年度の成果として公表されている^{（註２-５、２-６）}。
　本論はＳＣＯＲそのものの紹介が目的ではないので、以下にこれまでの活動で得られた関連資料を紹介するに止める。

◆【註２-１】 ＳＣＣがホームページで一般公開しているプレゼンテーション資料“ＳＣＯＲ Overview”に基づいて、分り易い日本語資料にしたものに「ＳＣＯＲ入門編」がある。本誌Vol.1(1998.Oct.) 「ＳＣＯＲ入門」（翻訳・編集：ＳＣＭ研究プロジェクト／�鞄�本ビジネスクリエイトＳＣＭ本部長 北風道彦）

◆【註２-２】 昨年の「ＳＣＭ提言セミナー」でのＰＲＴＭ（Pittglio Rabin Todd & McGrath）コンサルタント ケイト・フィックル女史の講演が実地の適用体験を踏まえた話しで分り易い。本誌Vol.2(1999.Feb) 「特集サプライチェーン・マネジメント提言セミナー第２部」の「ＳＣＯＲの概要紹介」および「ＳＣＯＲケーススタディ」参照（翻訳・編集：ＥＲＰ研究推進フォーラム主席研究員［当時］ 大石高至、同研究員 嘉屋吉郎）

◆【註２-３】 1998.Dec., Supply Chain Operations Reference (SCOR) Model Concept Development Workshop（Michael P.Novitsky, CPIM）参照

◆【註２-４】 1999.Apr., Supply Chain Operations Reference Model Workshop Slides（Scott Stephens, Chief Technology Officer, Supply-Chain Council, Inc）およびワークショップで使われたモデル企業に関する資料を参照

◆【註２-５】 本誌Vol.3(1999.May)「研究員研究成果報告論文集」「§１．ＳＣＯＲメトリクスとキャッシュフロー」（ＥＲＰ研究推進フォーラム研究員 嘉屋吉郎）

◆【註２-６】 本誌Vol.3(1999.May)「研究員研究成果報告論文集」「§２．ビジネスプロセスエンジニアリング」（ＥＲＰ研究推進フォーラム主席研究員［当時］大石高至）

 ２．ＳＣＭとビジネスモデル

（３）ＳＣＭとサプライチェーン マネジメント
　 我々は“ＳＣＭ”という用語を単なるシステムカテゴリーの一つとして扱うのではなく、言葉通りに“サプライチェーン マネジメント”と読む事にした。正確性を期して日本語訳するとすれば「供給活動連鎖の経営管理」とでもなろうか。中には熟語“ＳＣＭ”の発祥元であるパッケージシステム色を嫌って“サプライチェーン経営”と読み替える人もいる。サプライチェーン協議会等での論議もSupply Chain Managementはマネジメントの視点で語られており、システムアプリケーションのカテゴリーを指す場合には、
・ＳＣＰ（Supply Chain Planning）application
・ＳＣＥ（Supply Chain Execution）application
等と明確に使い分けている^{（註３-１）}。ただ、ＳＣＰソフトウェアベンダーのＳＣＥ領域への進出統合やＥＲＰベンダーのＡＰＳ（次項参照）機能への拡張の動向を見ると、この使い分けも早晩変わってこよう。
　いずれにしても、“ＳＣＭ”は“サプライチェーン マネジメント”の略語として一貫して扱っていく事にしよう。当「ＳＣＭリサーチレビュー」誌も、情報技術やシステム市場の観点の取り組みだけが中心課題ではなく、あくまでもこれらをソリューションの一部として扱う事になる^{（註３-２）}。 

＜図（３）ＳＣＭソリューションとしての情報技術←ｐｐｔスライド３＞

◆【註３-１】 “ＳＣＰ”および“ＳＣＥ”の定義と使い分けについては、本誌Vol.3 「特集−１．ＳＣＭと情報技術最前線」の「§１．米国を中心としたサプライチェーンシステムの展望」（”1999 Supply Chain Strategies Outlook” by the Supply Chain Strategies Group @ AMR Research Inc.）参照

◆【註３-２】 本誌Vol.2「巻頭言」（ＥＲＰ研究推進フォーラム主幹研究員 梅澤伊憲）参照

 （４）ＥＲＰとＳＣＭ

　ＥＲＰシステムの根幹をなす“ＭＲＰ（通常レベル�U）”に換わる、多くの場合ＴＯＣ理論などの先進的な計画管理技術を織り込んだ計画立案手法や機能を指す場合は、“ＡＰＳ”（Advanced Planning and Schedule）と呼ぶ。“ＡＰＳ”は、ＳＣＰパッケージが実装している計画手法なり機能を指す言葉である。従って、ＳＣＰパッケージとＥＲＰパッケージは“ＡＰＳ”機能を通してユーザーの“ＳＣＭ”市場に食い込む事を競っているのである。現実にＥＲＰシステムベンダーは、こぞってＡＰＳ機能を自製品に取り入れるかＡＰＳベースに組み替えようとしている^{（註４-１）}。
　このようにパッケージシステムソリューションの話がからんでくると分かり難くなってしまうが、マネジメントの対象とすべきビジネスプロセスの視点で見てみると課題は明白である^{（註４-２）}。

＜図（４）企業システムとＳＣＭ［コピー←Vol.1／55頁］（pptスライド１）＞

　 図（４）の下段はＡＰＱＣの定義した企業のビジネスプロセス（業務）の全体像である。そのビジネスプロセスの中の製品やサービスを顧客（企業）に提供するサプライプロセス（バリューチェーン）の部分を抜き出して、更に取引企業のビジネスプロセスとを連鎖させた絵が上段である。ここでは連鎖関係を解り易くするために、夫々の企業のサプライに関わるビジネスプロセスを“SOURCE”、“MAKE”、“DELIVER”という明解な定義に置き換えている。これを見ると、ＳＣＭとは企業間をまたがって最終顧客まで連鎖が続くビジネスプロセスを全体でどのように最適化すべきか、というところに視点がある事が解る。（“PLAN”プロセスが企業間をまたがって作用している）
　しかも、日本企業の経営者や事業部門の責任者達には「システムソリューションは難しく解り難い」、「システムは道具であって経営の直接課題ではない」という“システムコンプレックス”が根強い。他方、米国人は平気で「経営課題解決＝システムソリューション」という表現をする。これは、このような言い方・表現が実際的な課題提起やビジネスになると思ってそうしているのであって、彼らもコンピュータシステムだけで企業が運営できるとは考えていない。これから一層国際的な企業の統合再編や地域をまたがるサプライチェーンの再構築が進む事を考えれば、日本の経営者も「システムをソリューションの主要素の一つとして巧く使えるように」なる必要がある。

◆【註４-１】 ＥＲＰシステムベンダー各社のＡＰＳ機能への対応状況ついては、本誌Vol.3 「特集−１．ＳＣＭと情報技術最前線」の「§２．ＥＲＰ各社のＡＰＳへのアプローチ」（”Can I get APS from My ERP Provider?” by John Bermudez @ AMR Research Inc.）参照

◆【註４-２】 ＥＲＰおよび他のＩＴ（情報技術）の進展を含めた企業システム環境の今後については、「ＥＲＰ研究推進フォーラム第２年度報告書／アプリケーション研究分科会」の「�V章 ＥＲＰ動向に関する考察」（ＥＲＰ研究推進フォーラム主幹研究員 梅澤伊憲）参照

 （５）ＳＣＭとビジネスモデル

　ＳＣＭの実践には理論的かつ客観的なイニシャチブとアプローチを必要とする。サプライチェーンは、部門をまたがり、企業をまたがり、グローバリゼーションを一層推し進めるものだからである。異なる部門や企業が、同じ最終顧客に対する満足を提供できるサプライチェーンを構築するには、異なる部門や企業が共通に理解できる言語・記法で目的を記述し、現状を評価し合い、あるべき姿とそれに至る道筋を共通認識できなければならない。ＳＣＭを“エンジニアリング”として捉える事の必要性、“モデル化技法”や“参照モデル”の重要性はここにある。^{（註２-６、註５-１、５-２、５-３）}
　では、ＳＣＭに必要なモデルや記述方法論とはどのようなものか。一般的な要件として書き出すと以下のようであろう［作業のスケジューリングやプロジェクト体制に関するものは除く］。

�@【ＡＳ-ＩＳ記述】ＡＳ-ＩＳ（現状）のサプライチェーンを記述し、事実として客観的に関係者が共通認識できる用語、記法、手順（ツール）等

�A【metrics設定】測定し、部門間、企業間でベンチマーキング評価が必要なプロセスの抽出と、有効なmetricsを選択決定が出来る参照情報

�B【測定データ収集】ベンチマーキングのためにＡＳ-ＩＳシステムから収集すべきデータとデータ加工のための参照事例情報

�C【プラクティスＤＢ】ベンチマーキングの結果を評価してサプライチェーン変革の目標値を設定できる、グローバルな測定平均値、競合他社の測定値、優良企業の測定値に関する参照情報

�D【ＴＯ-ＢＥ設計】変革目標値が実現できるＴＯ-ＢＥ（あるべき）サプライチェーンを、設計、アレンジできるベストプラクティス情報

�E【変革項目設定】ＡＳ-ＩＳとの相違点が明確に記述出来、サプライチェーン変革項目が関係者に共通認識できる用語、記法、手順（ツール）等

�F【ソリューション選定】サプライチェーン変革項目を実現できる理論、方法論、ビジネスエンティティ、システムソリューション等を選択決定できる参照情報

�G【システムソリューション】システムソリューション情報（必要なデータモデルやパッケージのカスタマイズパラメタ）の生成

◆【註５-１】本誌Vol.1（1998.Nov.）「巻頭言」（�鞄�本ビジネスクリエイト 専務取締役 福島美明）

◆【註５-２】本誌Vol.1〜3（1998.Nov.〜1999.Mar.）「（連載）サプライ・チェーン・マネジメントの可能性を求めて」（(有)ビジネスダイナミックス研究所 代表取締役 今岡善次郎）参照

◆【註５-３】サプライチェーンを中心とするビジネスプロセス エンジニアリングの沿革とＳＣＯＲとの関連、および吉原先生御自身の多年のご経験の集大成である詳細業務モデルＰＤＲへのブレークダウン等については、本誌Vol.4〜6（1999.Aug.以降予定）「（連載）ビジネスプロセス・エンジアリングの進展」（�潟jックスシステム研究所 代表取締役 吉原賢治）をご期待ください

（６）ビジネスエンジニアリングとＳＣＯＲ
　昨年度のＳＣＭ研究プロジェクトのＳＣＯＲ研究では、ビジネスエンジニアリングの言語および方法論としてＳＣＯＲを理解し評価しようとした^{（前掲 註２-６）}。また、ＳＣＯＲワークショップへの参加や今年度のプロジェクトでの事例研究におけるＳＣＯＲ記述の適用^{（註６-１）}等から以下の事が解った。

＜図（６）ＳＣＯＲ全体像［コピー←Vol.2／21頁］＞

 【プロセス記述におけるＳＣＯＲの機能】

�@プロセスをツリー構造で記述する事が出来、記述に際して標準定義^［＊］されている内包下位プロセス群から選択して当てはめる事ができる［３レベルまで］

�A選択したプロセスの一般的な能力評価指標（メトリクス：metrics^［＊］）を知る事が出来、その中から実際に適用するメトリクスを選択する事ができる

�B選択したプロセスのベストプラクティス（一般的な適用理論や方法論^［＊］）を知る事が出来る＝ツリー構造によるプロセス定義なので、ＳＣＯＲ表記だけでは複数のプロセスにまたがって適用される理論や方法論（例えば、“製番管理”や“ＡＢＣ”、…）を、統合して定義したりプロセス間の整合性を検証する事はできない^[＊＊]

�C選択したプロセスへの適用可能な代表的なソフトウェア名（パッケージ名称^［＊］）を知る事ができる＝�Bと同様の理由で、下位プロセス層になるほど有効なアプリケーション機能の有無の評定が難くなる。しかも、パッケージ製品名だけの記載なので「当該プロセスに適用している事例がある」程度の参考にしか出来ない^[＊＊]

�Dこれらに登場する“用語”は用語集（glossary）としてまとめられており、用語自体の正確な普及と実際適用が意図されている

［＊］これらは全てＳＣＣの技術委員会（ＴＣ）が、参加メンバーの知識経験を持ち寄って討議することで不断にアップデイトされている。年に一度の改訂で“バージョンアップ”が、年度中の改定が“リリースアップ”としてオーソライズされメンバーに提供される。従って、改訂の方向や内容は、ＴＣメンバーの資質と今までの蓄積を基に評価調整を加えるボードメンバーの力量にかかっている

［＊＊］ＳＣＯＲの特質と日本市場への適合評価は“３（７）ＳＣＯＲの評価”の項参照

�Eこの言語としてのＳＣＯＲを実際のサプライチェーン（“ＡＳ-ＩＳ”であっても“ＴＯ-ＢＥ”であっても）に当てはめて記述を進める実際の方法論については、ＳＣＯＲ本体には前掲図（６）のレベル毎の概念的な記述^{（前掲註２-１）}があるだけである。この適用記述のノウハウがＳＣＭの実践あるいはコンサルテーションのノウハウと目されており、我々が受講した“ＳＣＯＲ Workshop”は正しくこの方法論のトレーニングであった（勿論、有料）。

�F更に、ＳＣＯＲのメトリクスを使って同業他社や異業種企業、特に優良企業（ＳＣＯＲでは“ベストインクラス：best in class”と表現）等と相対比較するベンチマーキング（benchmarking）が実施されている。ベンチマーキングの為には、適用metricsの抽出や評価データの収集と分析方法論等が必要となる。また、他企業のデータや過去からのトレンドが判る実績データの体系的な蓄積も必要である。これらを実施支援を事業としている企業の一つがＰＭＧ（Performance Measurement Group Inc.）である。

◆【註６-１】今年度の事例研究ＷＧで、発表事例をＳＣＯＲで記述する事を研究員ベースで試みている。本文中の適用方法論に沿った適用ではない事と事例発表企業の許諾を必要とする事から、現段階ではＷＧの内部検討用資料として扱っている

３．日本市場とＳＣＯＲ

（７）ＳＣＯＲの課題
　このようにビジネスエンジニアリングの視点から見てくると、ＳＣＯＲモデルを使うだけで企業のビジネスプロセスの再構築が進む訳ではないし、ＳＣＯＲ自体もまだまだ発展し拡充すべき課題を数多く抱えている。以下、（５）項で列挙した期待される参照モデルの要件とＳＣＯＲを対比してみよう。

＊プロセス記述共通語としての価値は高く、以下の各ステップで活用できる

  �@【ＡＳ-ＩＳ記述】（但し、Workshop方法論とトレーニングが必要）

  �A【ｍｅｔｒｉｃｓ設定】（同上）

  �D【ＴＯ-ＢＥ設計】（“記述”はできるが“設計”はできない）

  �E【変革項目設定】（同上）

＊以下の各ステップへの適用は、当初想定されていた痕跡はあるが使えない

  �C【プラクティス】＝プロセス定義・説明のための“コモンプラクティス”でしかない

  �F【ソリューション選定】＝適用するべき理論や方法論（例えば、ＴＯＣ、製番管理、ＶＭＩ、…）は記述できない。ほんの参考情報程度

  �G【システムソリューション】＝ＳＣＯＲの第３レベルでの適用評価では、掲載ソフト製品に相当する業務機能が“ありそうだ”位しか不明。適用検証は自らやるしかない

＊�B【測定データ収集】を含む、ベンチマーキングに向けたＡＳ-ＩＳシステム側の対応については全く考慮されていない

　ＳＣＯＲの仕様決定プロセスは（現在は）技術委員会を構成するボランタリーに依存するところが大きく、ビジネスプロセス エンジニアリング上での適用範囲や方法も試行錯誤の結果で現在は上記のようになっている、という状況である。従って、利用企業のグローバルな広がりや製造業種以外のインタレストが強くなって行く過程で、ＳＣＯＲの役割や管理方法はまだまだ変革の余地がある。
　このような状況下で、ＳＣＯＲは周辺に以下のようなビジネスチャンスを生み出した。これらはＳＣＣや少数の関連企業に独占されるべきものではなく、日本市場においても積極的な取り組みと成果を数多く作っていく必要がある。

・ＳＣＯＲ活用方法論の確立と活用ビジネス（今まではＳＣＣのプロモーション活動の一貫でWorkshopを実施してきたが、今年に入りWorkshop自体を採算ベースで扱う方向が見えてきた。前述のごとく、ＳＣＯＲ適用方法論はマダマダ工夫発展させる余地があり、独自の方法論を確立してインストラクションやコンサルテーションのビジネスに結び付ける事が充分可能である）

・ＳＣＯＲを活用したサプライチェーンのベンチマーキング（現在は、ＰＭＧ［ＰＲＴＭのベンチマーキング子会社］がグローバルに対応する形が早く過去の蓄積を活用できるとされているが、“企業レベル”から“サプライチェーンレベル”へ、“何でも比較”から“特定のインタレスト毎の対比分析”へ、等、工夫発展の余地は大きい）

・ＢＰＥツールへの組み込みとソリューションビジネス（ＳＣＯＲ活用の方法論、ベンチマーキング、システムインプリメンテーション等の一連のＢＰＥ［ビジネスプロセス エンジニアリング］過程をＳＣＯＲをベースにした統合ソリューション パッケージ化する動きである。当初のＣＯＢＲＥの単なる記述ツールから始まって、ＩＤＳやＰＨＩＯＳのようなリポジトリーを中心とした知識ベース化、さらにはパッケージシステムの連動インプリメンテーション等への発展が始まりつつある）

・パッケージビジネス（ＥＲＰを始めとするパッケージベンダーのビジネスも、ＢＰＥツールの組み込みや連動を伴って大きく変わってくる。“パッケージソリューションビジネス”から、ベンチマーキング支援を含めた“ＳＣＭソリューションビジネス”へ）

・インターネットビジネス、オブジェクトコンポーネントビジネス、…

（８）サプライチェーン協議会（ＳＣＣ）

  このようなＳＣＯＲを取り巻くグローバルな動きの中で、“ＳＣＭ全般の推進”を標榜してきたＳＣＣの役割や機能も大きく変貌していくだろう。

＊ＳＣＯＲの進展と維持：現在の技術委員会（ＴＣ）中心の活動は、意欲的なボランティア活動に支えられて今までの試行錯誤を何とか乗り切ってきた。しかし、今年度大会でのＳＩＧ（Special Interest Group：特定目的の分科会）の台頭や、日本などの米国流マネジメントだけでは扱いにくい地域・国からの参加が増えた事等、今後のＳＣＯＲ仕様の進展・維持体制を見直す必要性は急速に高まってきた。ＳＣＣ発足以来のＩＳＯ等の公的標準登録論議も一層活発化しよう。

＊このような中で、ＳＣＣが（本来の広義の）ＳＣＭ研究推進組識足り得るのかどうかも正念場である。今シカゴ大会を見ても、活動の主体が一層ＩＴ（情報技術）よりになってきている（ＳＣＭ領域が拡大してくれば適用ＩＴの幅も限りなく広がり、インターネット、ＣＴＩは言うにおよばず無線識別までが課題に取り上げられていた）。本来的に、参加企業の戦略性を基軸にしてコラボレーション関係等の一般論だけでは解決し得ない性質のＳＣＭを、（組織的には）拡大するＳＣＣが万遍なく取り仕切れるとは考えられない。そして、この事は、我が“ＳＣＭ研究プロジェクト”にも同じ課題となって表面化してきている。

＊他方、ＳＣＯＲを取り巻く周辺のビジネスチャンスも前述のように多様で幅広い展開を見せようとしている。これらは、よりオープンなビジネスチャンスとして世界中の企業や企業集団に提示されねばならない。ＳＣＯＲ標準を活用する種々のビジネスがＳＣＣを離れた多様な地域と場面で創生されていく事が、ＳＣＯＲの基本使命ではないだろうか。日本においても、誰かが、ＳＣＣがビジネス支援をしてくれる訳ではない事、自らがＳＣＯＲというオープンなシーズを花咲かせ結実させねばならない事、に気付かねばならない。そして、これを支えるために、（グローバル標準としての）ＳＣＯＲの維持管理体制を、より強固なものに発展させていく必要がある。

（９）ＳＣＭ推進センター構想

このようなＳＣＯＲおよびＳＣＣに対する認識の下に、日本におけるＳＣＭ進展の鍵は以下であろう。

�@日本においては、ＳＣＭのバックボーンとなる理論や方法論が客観的な表現で体系化される事があまり無く、米国で体系化されネーミングされたものが逆輸入されるのが一般的である。企業個別の工夫努力が、グローバルなイニシャチブに発展できるようなメカニズムが必要である。

＜図（９）−１．ＳＣＭソリューションとしての理論、方法論←pptスライド２＞

�AＳＣＯＲモデルの（日本市場での有効活用に向けた）発展を、現在のＳＣＣの低料金・ボランタリーに依存するのではなく、公的な標準として進展させＳＣＣＩ（グローバルなＳＣＣ体制）に参画し協同する

�B兎角業界別やシーズ別（ＥＲＰ、ＳＣＰ、ＥＣ、ＣＡＬＳ、ＯＯ、…）になりがちなシステム化推進活動を、“ＳＣＭ”を解決基盤として相互調整できるメカニズムが必要

＜図（９）−２．ＳＣＭ推進センター構想←pptスライド４＞

  ＥＲＰ研究推進フォーラムとしての“ＳＣＭ研究プロジェクト”に一区切りつけるに当たり、以下の機能役割を担う事の出来る準公的機関の設立を再度提案するものである。

�@ＳＣＭに関わるビジネスエンジニアリング、経営方法論の基礎研究と企業育成

�AＳＣＯＲモデルの公的標準としての進展・維持と適用推進

�BＳＡＩ^{（次項参照）}基準の設定とニーズ間、シーズ間および相互の調整と発信（要件提示）

４．追補

（10）ＥＡＩからＳＡＩ（Supply chain Application Interoperability）へ

  “ＳＣＭ推進センター”構想に付帯して触れた“ＳＡＩ”について簡単に触れる。

  昨今の米国ソフトウェア市場において、ＡＭＲ等は企業（内）アプリケーションシステムを統合する概念としてＥＡＩ（Enterprise Application Integration）を打ち出している。これは、ＥＲＰやＳＣＰと各種の実行系システム（ＭＥＳやＦＳＡのような）とを、共通のシステムプラットフォーム上で統合して扱う事を目的とするモデル（ＲＥＰＡＣモデル^{（註７-１）}）と、それを実現する方法論や情報技術に関するコンセプトである。「ＥＲＰパッケージ間連携（ＯＡＧ、…）」、「ＥＣ、ＣＡＬＳの実用プロジェクト（日本ではＪＥ−ＣＡＬＳ）」、「オブジェクトコンポーネント間統合（ＯＭＧ、ＣＢＯＰ、…）」、「マイクロソフト プラットフォーム上のアプリケーション連携（ＶＣＩ^{（註７-２）}）」等のシーズ側からの取り組みを、アプリケーション側から包括的に体系化しようとしているものであり、パッケージシステムがベースのＥＲＰの、“次”の企業システムソリューションと目されている。

  私は、このＥＡＩを“ＳＣＭ”にフォーカスしてより目的を具体化させる為に“ＳＡＩ：Supply chain Application Interoperability”という概念を提案したい。企業中心の“システム統合”の視点から、企業間サプライチェーンをまたがる“相互運用性の確保”へ視点を広げる事が狙いであり、今後の一層のインターネット活用段階に素早く適合していくために必須の取り組みだと考える。本項については、別の機会に詳述する。

◆【註７-１】ＲＥＰＡＣモデルについては、本誌Vol.4（今号,1999.Aug）「（生産モデル）求められる新しい工場システムモデル」（Do We Need a New Model for Plant Systems? By Bill Swanton @ AMR Research Inc. 1998 Oct.）参照

◆【註７-２】Value Chain Initiative。マイクロソフト社が主導する同社のＤＮＡ（Distribute Network Architecture）上で稼動するアプリケーションを共同開発し、再利用可能なコンポーネントをユーザー間でシェアしようとの試み。日本でもこの秋から正式に活動を開始する。(1999.Jul.、Commerce Solutions Briefing)

 （1999年7月　梅澤）