ＳＣＭ設計とＳＣＯＲ[SCC報告]：ロジスティクス・ビジネス[LOGI-BIZ]バックナンバー

2001年10号

SCC報告
ＳＣＭ設計とＳＣＯＲ

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

OCTOBER 2001 66 短期集中連載の最後となる第三回目は、ＳＣＯＲのレファレンスモデルとしての意義と課題について述べる。
地理マップ、スレッドダイヤグラム、スイムチャート等についての議論は、実際にワークショップを受けた方でないと理解できないと思われるので、別の機会に譲る。
また、これまでの連載を読み、ある程度のＳＣＯＲの知識が読者側にあることを前提とした。
これを補うには、ＳＣＯＲのディクショナリー（注１）や解説を参考にして読んでいただきたい（注２、３）。
１．ＳＣＯＲでのＳＣＭ設計のステップ１―１　�
咤達錬劼離譽戰襪硲咤達誉澤� 図１に示すように、ＳＣＯＲではＳＣＭの設計ステップに合わせて、ＳＣＯＲのレベルを層別している。
レベル１では、分析やＳＣＭのパフォーマンス、ＳＣＭのスコープを決定する。
レベル２では、モノの流れを可視化する。
レベル３では、情報や業務の流れを可視化する。
レベル４以降は各プロジェクトごとにシステムの実装を目的としてプロセスを記述する。
このように、ＳＣＭ設計に限定して、階層的に各レベルで何を設計・決定すべきかを明確に定めている点がＳＣＯＲの特徴である。
以下、ここでは標準化されているレベル３までについて議論する。
参考のために各レベルのプロセス一覧を表１に示す。
これらのレベルのうち、レベル２とレベル３は使用され第7回ＳＣＭ設計とＳＣＯＲサプライチェーンカウンシル日本支部　チェアマン毛利峻治（日立製作所　生産技術研究所）これまでサプライチェーン設計の方法論は各社によってバラバラだった。
そのため他社や過去の取り組み成果を蓄積し、再利用することが難しかった。
ＳＣＯＲを活用することで、それが可能になる。
国籍を問わず、ＳＣＭの成果を利用し、広く普及させることができるという。
短期集中連載〔第三部〕ＳＣＯＲワークショップ・エグゼクティブサマリーレベル1 競争条件の分析レベル2 サプライチェーンの再構築レベル3 業務/システムの施策具体化レベル4 ビジネスプロセスの定義レベル5 システムの実装図１　�
咤達錬劼砲茲覯�廛好謄奪� 決定項目ＳＣＭのスコープＳＣＭパフォーマンス評価（レベル1の12項目）全体の可視化、定量化ＳＣ全体の地理マップＳＣ全体のプロセス設計（２６のプロセスで記述）モノの流れの可視化現状プロセス(As-Is) プロセス改革案（To Be Process Design）情報･業務の流れの可視化業務プロセスのタスク分解効果算定マスタ計画（基本、拡張）機能･分掌の可視化システム詳細設計効率の良いワークフローの可視化ＳＣスコアカード作成（ベンチマーキング）ＳＷＯＴ分析ギャップ分析構造問題の摘出非接続（disconnect）解析重複（ムダ）、不足ボトルネック解析業務問題の摘出改革目標のプロセスへの配分効率・品質メトリクス業務プロセスモデル（業務名レベル）業務手順とパッケージ機能との対応（アクティビティ毎）新業務フロー競争力強化目標設定目標のランク分け議論の際にﾚﾍﾞﾙ2 　以下を論じない拠点(製販在)配置生産･物流方式組織、意思決定項目業務ルール業務仕様タイムチャートツール選択ビジネスプロセスビジネスデータビジネスルール実施組織、分掌アクティビティ処理プロシージャ対応ＳＣＯＲレベル記述目的記述内容 67 OCTOBER 2001 ＥＳ1 SOURCEビジネスルールの管理ＥＳ2 サプライヤパフォーマンスの評価ＥＳ3 SOURCEデータの維持ＥＳ4 プロダクト在庫の管理ＥＳ5 設備資産の管理ＥＳ6 プロダクト受入管理ＥＳ7 サプライヤネットワークの管理ＥＳ8 輸出入要件の管理ＥＳ9 サプライヤ契約の管理ＥＭ1 MAKEビジネスルールの管理ＥＭ2 生産のパフォーマンス管理ＥＭ3 MAKE情報の管理ＥＭ4 仕掛品（WIP）の管理ＥＭ5 MAKE設備と施設の管理ＥＭ6 輸送管理（WIP）ＥＭ7 製造ネットワークの管理ＥＭ8 MAKE規制遵守の管理ＥＤ1 DELIVERビジネスルールの管理ＥＤ2 納入パフォーマンスの評価ＥＤ3 DELIVER情報の管理ＥＤ4 完成品在庫の管理ＥＤ5 DELIVER資産の管理ＥＤ6 輸送管理ＥＤ7 製品ライフサイクル管理ＥＤ8 輸出入要件の管理ＥＤ9 顧客からの返品管理Ｐ1-4 サプライチェーン計画の確立と通知Ｐ3-1 製造要件の特定、優先順位付け、及び集約Ｐ3-2 製造リソースの特定、評価、及び集約Ｐ3-3 製造要件と製造リソースのバランス度合いの把握Ｐ3-4 生産計画の確立Ｐ4-1 納入要件の特定、優先順位付、及び集約Ｐ4-2 納入リソースの特定、評価、及び集約Ｐ4-3 納入リソースと納入要件のバランス度合いの把握Ｐ4-4 納入計画の確立表１　SCORプロセス一覧Ｐ1-1 サプライチェーン全体の要件の特定、優先順位付け、及び集約Ｐ1-2 サプライチェーン全体のリソースの特定、評価、及び集約Ｐ1-3 サプライチェーン全体の要件とリソースのバランス度合いの把握ＥＰ1 Planビジネスルール管理ＥＰ2 サプライチェーンのパフォーマンス管理ＥＰ3 PLANデータの収集と管理ＥＰ4 統合サプライチェーン全体の在庫管理ＥＰ5 統合サプライチェーン資産の管理ＥＰ6 統合されたサプライチェーン輸送の管理ＥＰ7 計画編成の管理ＥＰ8 PLAN規制要件と遵守の管理ＥＰ9 サプライチェーンの各計画と財務計画との統合Ｐ2-1 プロダクト要件の特定優先順位付け、及び集約Ｐ2-2 プロダクトリソースの特定、評価、及び集約Ｐ2-3 プロダクト要件と資材リソースのバランス度合いの把握Ｐ1-4 調達計画の確立Ｐ１サプライチェーン計画Ｐ2 Source Ｐ３ Make計画Ｐ４ Deliver計画ＥＤＥＰＥＳＥＭ PLAN Source Make Deliver Ｓ1 Source見込生産プロダクトＳ1-1 プロダクト納入のスケジューリングＳ1-2 プロダクトの受領Ｓ1-3 プロダクトの承認Ｓ1-4 プロダクトの移送Ｓ1-5 サプライヤへの支払承認Ｓ2 Source受注生産プロダクトＳ2-1 プロダクト納入日程のスケジューリングＳ2-2 プロダクトの受領Ｓ2-3 プロダクトの承認Ｓ2-4 プロダクトの移送Ｓ2-5 サプライヤへの支払承認Ｓ3 Source受注設計生産プロダクトＳ3-1 サプライソースの識別Ｓ3-2 サプライヤの最終選定と交渉Ｓ3-3 プロダクト納入のスケジューリングＳ3-4 プロダクトの受領Ｓ3-5 プロダクトの承認Ｓ3-6 プロダクトの移送Ｓ3-7 サプライヤへの支払承認Ｍ1 見込生産Ｍ1-1 製造スケジューリングＭ1-2 資材／仕掛品の搬入Ｍ1-3 製造とテストＭ1-4 梱包Ｍ1-5 完成品仮置Ｍ1-6 完成品のDeliver プロセスへの移管Ｍ2 受注生産Ｍ2-1 製造スケジューリングＭ2-2 資材／仕掛品の搬入Ｍ2-3 製造とテストＭ2-4 梱包Ｍ2-5 完成品仮置Ｍ2-6 完成品のDeliver プロセスへの移管Ｍ3 受注設計生産Ｍ3-1 製品設計の最終確定Ｍ3-2 製造スケジューリングＭ3-3 資材／仕掛品の投入Ｍ3-4 製造とテストＭ3-5 梱包Ｍ3-6 完成品の仮置Ｍ3-7 完成品のDeliver プロセスへの移管（Ｖ4に無し）Ｄ1 Deliver 見込生産プロダクトＤ1-1 引合と見積Ｄ1-2 オーダの受領、入力と確認Ｄ1-3 在庫引当と納入日の設定Ｄ1-4 オーダの集約Ｄ1-5 積載の計画策定Ｄ1-6 出荷ルートＤ1-7 輸送業者の選択と出荷料金の値決めＤ1-8 倉庫での製品受領Ｄ1-9 出荷プロダクトのピッキングＤ1-10 車載、出荷書類作成、与信検証、プロダクト出荷Ｄ1-11 顧客先でのプロダクト受領と確認Ｄ1-12 プロダクトの据付Ｄ1-13 請求書発行（Ｖ4に無し）Ｄ2 Deliver 受注生産プロダクトＤ2-1 引合と見積Ｄ2-2 オーダの受領、入力と確認Ｄ2-3 在庫引当と納入日の設定Ｄ2-4 オーダの集約Ｄ2-5 積載の計画策定Ｄ2-6 出荷ルートＤ2-7 輸送業者の選択と出荷料金の値決めＤ2-8 出荷プロダクトのピッキングＤ2-9 車載、出荷書類作成、与信検証、プロダクト出荷Ｄ2-10 顧客先でのプロダクト受領と確認Ｄ2-11 プロダクトのテストと据付Ｄ1-12 請求書発行（Ｖ4に無し）Ｄ3 Deliver 受注設計プロダクトＤ3-1 提案依頼（RFP）／見積依頼（RFQ）の入手と回答Ｄ3-2 契約の交渉と成立Ｄ3-3 オーダ入力、リソースの確保、プログラム開始Ｄ3-4 据付日程の設定Ｄ3-5 積載と出荷の計画策定Ｄ3-6 ルート決定と輸送業者選択Ｄ3-7 出荷プロダクトのピッキングＤ3-8 車載、出荷書類作成、与信検証、プロダクト出荷Ｄ3-9 顧客先でのプロダクトの受領と確認Ｄ3-10 プロダクトのテストと据付Ｄ3-11 請求と支払い受領 OCTOBER 2001 68 ているプロセスカテゴリー名（例：Ｐ１サプライチェーン計画、Ｍ１Make 見込生産）やプロセス要素名（例：Ｐ１．１サプライチェーン全体の要件の特定、優先順位付け、及び集約、Ｍ１．１製造スケジューリング）になじみがあり、また図表の書き方もスレッドダイヤグラム、スイムチャートとして定型化されており、比較的理解しやすい。
しかし、レベル１はPlan,Source,Make, Deliver,Return （ＳＣＯＲ　�
孱粥� ０）の五つのマネジメントプロセスが定義され、さらに十二個のメトリクスが定義されているのみである。
メトリクスにはＳＣＣの定義もあり、その使用法も大まかには理解できるものの、マネジメントプロセスをどう使用すればよいのかについては明確な規定がない。
しかし、レベル１は実は、レベル２、レベル３に劣らず非常に重要なステップであると思っている。
以下、それについて示す。
１―２ＳＣＭ設計の手順とレベル１の意義ＳＣＭ設計の手順については、これまでにいろいろと報告されているが、およそ以下の五段階の手順に集約できる。
手順１：ＳＣＭの正しい理解、プロジェクトの進め方のコンセンサス、体制作り手順２：環境分析：自社・他社競争力、商品の特徴と市場の性格、ベンチマーキング、ＳＣＭ改革の意義の共通認識手順３： As ― Is 分析：現在のプロセス調査（物流、商流、金流）とボトルネック解析手順４： To ― Be プロセス設計：機能分析、機能・分掌分析手順５：システム実装：機能・パッケージ対応これらの五段階の手順を何度も繰り返し、継続的最適化を行うわけである。
この手順は、レベルの概念が明確には出ていないので、レベル・バイ・レベルで深く掘り下げて行くというやり方は明確ではないが、ほぼＳＣＯＲのレベル２、３が手順３、４に対応していると考えていいだろう。
これによれば、レベル１は、ＳＣＭプロジェクト編成に始まり、ビジネス環境の分析を行うレベルであるといえる。
そのためには、ヒヤリングや質問票により物流調査、製造プロセス調査、業務フロー調査、財務状況等の調査を行う必要がある。
それらをまとめて「ＳＣＭ改革の基本方針」を作成し、ＳＣＭ改革の意義（グランドデザイン）を確立する。
こうした際、実際のＳＣＭプロジェクトでは、ややもすると詳細なレベル２以下の議論が出てきて、収拾がつかなくなることがある。
それをＳＣＯＲではレベル１で検討を行うことを明確にすることによって、首尾一貫した図２　サプライチェーン統合の例（ＳＣＯＲレベル２のスレッドダイヤグラム(BPR設計)）旧ＳＣ (AS-IS) 問題点　 P1重複計画非共有間接配送主サプライヤ新ＳＣ (To-Be) P1連携計画共有直送化 P1 P2 P3 P2 M2 S1 M1 P1 P4 D1 D1 D2 P2 P2 P1 P3 S1 M2 D2 P2 P4 S2 M1 P4 D1 S1 P2 P1 D1 P4 S2 S2 その他サプライヤ P3 P4 PLAN EP Planイネーブル P1 サプライチェーン計画 P2 Source計画 P3 Make計画 P4 Deliver計画 S2 Source受注生産 SOURCE ES Sourceイネーブル S1 Source見込生産材 S2 Source受注生産 S3 Source受注設計資材 MAKE EM Makeイネーブル M1 Make見込生産 M2 Make受注生産 M3 Make受注設計生産 DERIVER D0 Dreliverインフラ D1 Dreliver見込生産製品 D2 Dreliver受注生産製品 D3 Dreliver受注生産製品サプライヤメーカー（自企業）サプライヤ顧　客 69 OCTOBER 2001 「ＳＣＭの目的のみの議論」ができるようにしている。
また「ＳＣＭの構成は五つのマネジメントプロセスで理解せよ」としていることも特徴であろう。
これは、議論を五つに分類して実施することを示唆している。
例えばミーティングの始めに「本日はSource について議論しよう」というだけで、議論が集約できるので大きな意義がある。
調査の項目についても、調査のまとめについても同じようにまとめて行うことを示唆している。
レベル１メトリクスは目標の定量化に寄与するし、マネジメント・プロセスは調査・議論のまとめ方に寄与する。
使用するパッケージは同じでも、実際にできあがるシステムは良くも悪くもなる。
要は、最初の方向付け、グランドデザインが重要である。
これを効率よく・漏れなく行うために、レベル１の存在は大きな意味を持つ。
しかし、これを一律に定式化することには難しさがある。
今後のＳＣＯＲによるＳＣＭ設計方法論の一つの課題であろう。
１―３　レベル２レベル２では、計画系（Plan ）の対象である五つマネジメントプロセス（Plan,Source, Make,Deliver,Return ）を、対象ごとに Source 計画の様に細分化し、また、実行系（ Source,Make,Deliver,Return ）では、生産方式の違いにより「見込」「受注」「受注設計」の三つの方式に細分化する。
この細分化はサプライチェーンの問題点を抽出するには粗すぎるきらいはある。
同じＰ１で表す計画系でも、実際の業務の詳細は相当違うものである。
しかし、レベル３以降の業務の細かな違いにとらわれずに、大鉈を振るって、「ここのＰ１とあそこのＰ１は重複している」といったサプライチェーン構造を大きく変革するには妥当な「粗さ」であるといえる。
レベル２の事例を図２に示す。
この図を見ればレベル２のもう一つの意義が分かる。
すなわち、このレベルの用語は生産の専門家でなくても理解できる。
投資判断をする経営幹部にもよく理解される。
専門家でなくても、サプライチェーンがどう変わるかが一目で理解できる複雑さであるといえる。
しかし、詳細業務を無視したレベル２での抽象化は、粗すぎることも事実である。
たとえば、ある製造工程を一律に「見込生産」とは言えないかもしれない。
これに対処するには工程を、細分化していき、三つの生産方式で記述できるくらいに分ければよい。
これは一つの事業所内でも複数のサプライチェーンが存在することを明確に認識するので都合がよい。
すなわち、商品の系列による生産方式の細かな違い、同じ商品でも顧客による違い、販売ルートによる違いなどにより発生するサプライチェーンの違いについて記述すれば、全体を一つにするような記述ではなくなるし、また、場合によってはなぜサプライチェーンを別々に分けねばならないのかの議論にも発展する。
１―４　レベル３「 As ― Is 」を記述することはとくに重要だ。
業務プロセスは、実際に、それを実行するものにとって見えているようで、実は見えていないことが多い。
複数部署にまたがる業務の流れ全体を把握している人はいない。
また人によって仕事の仕方が違う、特急、不良時には別のプロセスが必要など正確な記述が難しい。
ボトルネック解析も難しくなる。
通常は何でもないプロセスが、特急が発生すると急にボトルネックになったりする。
業務プロセスの記述には時間が掛かる。
日本においては日常行われている作業を改めて記述し、分析することに対して、無駄な作業をしているととられがちである。
しかし、業務プロセスを一度書き下すことで、議論をする土台ができる。
「確かにこうしている、しかしこうした方が更に良い」といった議論ができるようになるわけである。
情報共有の目的は、共有した情報をベースにお互いに意見を言って、最適な解を得ることであり、これを可能にすることが「 As ― Is 」を記述する意味である。
問題となるプロセスだけに絞り込んでも「 As ― Is 」プロセスは書くべきである。
２．レファレンスモデルの意義２―１　標準言語（オントロジー）ＳＣＭの範囲はサプライヤーのサプライヤ OCTOBER 2001 70 ーから、ユーザーのユーザーまでに及ぶ。
ＳＣＭ改革に参加するプレイヤーは数多く、参加各社によって文化も用語も違う。
ＳＣＭを議論するには用語を定義した共通言語が欠かせない事はすぐに理解できる。
共通言語を持つメリットはそれだけではない。
参加企業の使用している用語とは違う標準用語を用いることで、「客観的立場」での議論ができるのである。
自分たちの普段使用している用語と違い、細かいニュアンスにはとらわれないで、議論できる。
ただし、これは危険な面も持ち合わせている。
すなわち、各企業とも業務として行っていることは、大体同じでも、商品の性格、業務上で抱える問題は違う。
ＳＣＯＲでは各社で同じプロセス名称で表現されるものも、個々のオペレーションの重みが違う。
それをフラットに書き下したレファレンスモデルで議論することの限界はある。
また、どうしても表面的な議論になりがちである。
そのため、ＳＣＯＲでは共通化できるレベルがどこまでかを慎重に決め、レベル３のプロセス要素を定義している。
また、プロセス要素名も汎用化して一般的用語を用いている工夫が見られる。
現在、ＳＣＯＲではレベル３までしか規定していない。
そこまでで複数企業や部署間での改革のコンセンサスを得て、共通のプロセス設計をしたら、それから以降は各企業や各部署の言葉で、ニュアンスと重みを付けて翻訳することにしている。
２―２　記号化ＳＣＯＲのもう一つの特徴は、階層化された記号化表現である。
アイコンがコンピュータ操作をわかりやすく、かつ簡便化しているように、記号化されたシンボルはプロセス設計をわかりやすく、容易にする。
図２のよう P2 Source 計画 P3 Make 計画 P4 Deliver 計画 P4 Returnr 計画表2　ビジネスモデリングツール比較・米国ＳＣＣが提唱(1997)しているサプライチェーン設計ツール・Ｖ4が公開（米国ではＶ5）・プロセスとメトリクスを併記・PMGによるベンチマーキングが可能・計画､調達､製造､納入､回収よりなる・レベル3までが標準、それ以下は個別・As-Isの現状記述とギャップ分析によるTo-Beの理想記述ができる。
　（但し、理想システム策定法は無い）・業務のボックス毎にサイクルタイム、コスト、品質等や特性が付与・入出力情報の関連（Ｖ4で改善）や条件（同期化）が記述できない・現状ＳＣＣメンバのみへの公開　（メンバフィー：2000＄／年) ・ＳＣＭに的を絞り、各レベルで何を記述し、何を決定するかを明確に規定・ザールランド大学（独）シェアー教授が提唱（1992）・1998.2にＩＤＳジャパンが設立・ビジネスモデルの分析、記述ツール・ビジネスプロセスを要求定義、仕様設計、構築記述にわけ、ビューを組織、データ、制御、機能に分けて記述・上記3プロセスと4ビューを12個のマトリクス（ＡＲＩＳハウス）で表現・ＳＡＰ／Ｒ3のＩＭＧとのリンク可能・ＳＣＯＲ表現が可能(EasySCOR) ・標準業界モデルは1件約1Ｍ￥機械業界、プラントエンジニアリング、消費財流通、製紙業界、貿易･商業、自動車部品、公共・電力・ガス、什器・家具、化学、通販、県庁・市役所、保険、ＳＣＯＲ・米国D.T.ロスが提唱（1970年代）　（当時SADTと呼ばれた）・海軍のＩＣＡＭプロジェクトで使用　（ICAM-Definition：1985）・アクティブビティボックスに対する入力、出力、コントロール、メカニズム（実行組織等）で記述する・IDEF0：機能記述　IDEF1：情報関連図　IDEF1X：RDBの論理設計要情報関連図　IDEF2：動的シミュレーション　IDEF3：業務プロセスの時間的フロー　IDEF4：オブジェクト指向設計図式　IDEF5：オントロジー獲得構造図・一般ユーザ：IDEF3でのプロセス記述システム分析者：IDEF0,IDEF1,IDEF4 システム開発者：IDEF1X,IDEF1,IDEF4 ・自然言語での記述で親しみやすい・階層的記述をするが、各階層で何を記　述するかが決められていない（汎用的記述ツールであるため） http://www.supply-chain.gr.jp/ http://www.ids-scheer.co.jp/ http://www.idef.com/ 要件仕様設計構築記述要求定義仕様設計構築記述コントロール入力出力計　　画調達回収回収製造納入 P1サプライチェーン全体計画 EPイネーブル計画計画要件定義仕様設計構築記述要件定義仕様設計構築記述要件定義仕様設計構築記述メカニズムアクティビティＳＣＯＲＡＲＩＳＩＤＥＦしかし、決定項目が決められているので、それにない項目が出てくると難しくなる。
たとえば、「在庫を最小にかつ納入リードタイムを最短にするためのプロセスはどうあるべきか」というサプライチェーンではごく当たり前のことがＳＣＯＲでは記述しにくい。
これは工夫次第なのであるが、この様な例題の手順等の開発は今後の課題であろう。
３―２コラボレーションＳＣＯＲのプロセスは一企業内の流れのように書いてあるが、これは別に各プロセス要素が同一企業にあることを強制はしていない。
従って、共同して調達をするようなケースでは、「Ｐ２ ―１」は自社で行い、「Ｐ２―３」はサプライヤーで行い、「Ｐ２ ―４」は両者で行うようなプロセスにすればよい。
しかし、このためにはイネーブル（すなわちデータの共有方式等）に少し工夫がいる。
この課題は、文献（4）で詳細に議論されている。
３―３　他の記述ツール今回はＳＣＯＲのプロセスに集中して議論した。
その他の代表的プロセス記述ツールについては、比較表のみを表２に示すことで、詳細は省略する。
４．おわりに今回はＳＣＯＲのプロセスについてＳＣＭ設計にどう使用するかという立場で解説した。
71 OCTOBER 2001 に、簡素化されたサプライチェーンの記述を可能にし、わかりやすさを増加させる。
プロセス設計はこれで十分に簡便化できるが、各種チャートについてはまだ記号化が十分ではない。
特に物流（地理マップ）やスイムチャートでは、記号化の基準を決める等の工夫の余地があるが、今回はこれ以上は触れない。
２―３　レファレンスレファレンスモデルとしての性格上、ＳＣＭ設計における業務プロセスのすべての考慮事項が記述されている。
従って、設計時にこれを参照すれば、種々の項目を漏れなく検討することができる。
しかし、ＳＣＯＲはあくまでもレファレンスモデルであり、参照して利用できるところを利用すればよいものである。
無理にモデルを解釈して実業務フローに適用することは避けなければならない。
あくまでサプライチェーンの最適化が目的であるのだから、現実にジャストフィットするシステムにしなければ意味がない。
これはメトリクスやベストプラクティスも同様である。
現状で数値をとれないメトリクスに固執する必要はない。
ベストプラクティスについては、さらに考慮がいる。
すなわち、ＳＣＯＲでのベストプラクティスはプロセスベンチマーキング（業界、業種を問わず、そのプロセスをベストに実施しているところとのベンチマーキング）としてのベストプラクティスが多く、その記述もＤ１の「ＶＭＩ（ Vender Managed Inventry：サプライヤーの管理責任下で納品先に置く在庫）」のようにそれ自身が大きなＳＣＭの課題であることもある。
ＳＣＯＲにおけるベストプラクティスの処理は今後、さらに洗練される必要がある項目である。
３．記述ツールとしてのＳＣＯＲ３―１　記述性ＳＣＯＲは本来、サプライチェーンの設計ツールであり、システムの記述ツールではない。
システムの実装までをＳＣＯＲが連続的にサポートしているわけではない。
しかし、記述ツールとしてＳＣＯＲを見た時、そこにはいくつかの有効な特徴がある。
サプライチェーンを階層的に記述する際に、ＳＣＯＲではレベルを規定し、そこでの決定項目（すなわち記述の留意点）を定めていることである。
これを定めないでサプライチェーンを記述していくと、意味のあるのは最終レベルのアクティビティの流れだけになってしまう。
いくつかのアクティビティのボックスを集めて、名称を付けるのであれば、階層はいくつにでもできるし、統一された階層の表現ではなくなってしまう。
この階層では、これを記述する（すなわちこれを決める）というトップダウンの明確な指針なしで記述してしまうからである。
ＳＣＯＲを用いることで、こうした事態を避けられる。
OCTOBER 2001 72 このような標準言語を用いる利点は、（１）わかりやすい記述ツール（２）効率の良いコミュニケーション（情報共有・情報伝達）ツールであることは述べたが、（３）標準されたものであるため、情報蓄積のツールにもなる。
今まで、個別の方法論で作られてきたサプライチェーンが、ＳＣＯＲを利用すれば国籍を問わず結果の利用が可能になる。
また、ＳＣＯＲを基に作られた方法論は、すぐに普及できる。
実は、これが一番大きな利点であろう。
これを蓄積、普及して行くことがサプライチェーンカウンシル日本支部の一つの任務でもあると思っている。
ＳＣＯＲは今も進化しており、開発・設計のプロセスもシンガポール支部で研究されている。
これらは全て会員企業のボランティア活動であり、自主的に参加することで会員にも大きな成果が戻る。
本誌の読者にも是非サプライチェーンカウンシルへの参加と自主的な活動をお願いしたい。
(http://www.supply-chain.gr.jp 、参加費二〇〇〇ＵＳドル／年）なおＳＣＯＲ以外にもプロセス記述のためのツールは既に色々あり、ＳＣＣではそれらを調査したが、今回その詳細はすべて省略せざるを得なかった。
調査にご協力いただいた方にはお詫び申し上げる。
以下に文献をあげておくので、それを読まれることを薦める。
注／参考文献 (1) サプライチェーン・オペレーションズ・レファレンスモデルＳＣＯＲ第４版：サプライチェーンカウンシル日本支部(2001) （会員にのみ販売） (2) 北風道彦：ＳＣＯＲ入門編：ＳＣＭ Research Review Vol.1 1998 Autumn P.77-83(1998) (3) ケイト･フィックル（大石高至訳)：ＳＣＯＲの概要紹介：ＳＣＭ Research Review 1999 Vol.3 Winter P.18-34(1999) (4) Michelle Lohse, Jeffrey Ranch : Linking CPFR to SCOR Imation ﾕ s Experience : Supply Chain Management Review July/August 2001 P.56- 62(2001) (5) 研野和人、柏崎孝史、谷岡雄一：仕事の流れの記述法IDEF( 上 )( 中 )( 下 )：日経メカニカルNo.430 P . 7 8 〜 8 3 ( 1 9 9 4 . 6 . 1 ) 、 N o . 4 3 1 P . 8 6 〜 91(1994.6.27) 、 No.432 P.98 〜 195(1994.7.11) (6) 特集　ビジネスプロセスの分析手法：オペレーションズ・リサーチ　V o l . 4 2 , N 0 . 4 P . 1 8 1 - 209(1997.4) (7) 特集：ビジネス・プロセス・イノベーション：経営システムVol.6,No.4P.293-330(1996.12) (8) 小特集「エンタプライズモデリングとＡＩ技術」：人工知能学会誌　VOL.13,No.6 P.862-895 (1998.11) (9) T.J.Williams,P.Bernus,J.brosvic,D.Chen, G.Doumeingts,L.Nemes,J.L.Nevins,,B.Vallespir, J.Vlietstra, D.Zoetekouw： Architectures for integrating manufacturing activities and enterprises: COMPUTERS IN INDUSTRY 24 P.11-39(1994) (10) 益満環、安田一彦：ビジネスプロセス・モデリング・ツールの現状：オペレーションズ・リサーチ Vol.45 No.4 P.173-178(2000.4) （文献 (11) のダイジェスト版） (11) 益満環、安田一彦：ビジネス・モデリング・ツールの分類：東北大学　研究年報「経済学」 Vol.61,N0.3 P.155-168(1999.11) (12) ARIS EasySCOR4.0 : http//www.ids-scheer. co.jp/products/aris_easyscor/index.html (13) SCOR Wizaed : http//www.mi-servicesgroup. com (SCOR Version5.0 用のツール) (14) ビジネスプロセス・モデリングツール１６製品を４種に分類　現場視点で評価を下す：ソリューションＩＴ　No.148 P.68-77(2001.8) (15) ＳＩ現場で活躍するＸｕｐｐｅｒ：ソリューションＩＴ　No.142 P.89-95(2001.1)