【SCMフレームワーク】SCORモデルの全体像と6つのマネジメント領域

日本ではあまり知られていないSCMフレームワークに、SCOR（スコア）モデルがあります。

この記事は、次のような場面にいる方に向けて書いています。

• SCM改善プロジェクトで、課題を整理するためのフレームワークを探している
• 有識者インタビューの前に、とっかかりとしてSCMの全体像を把握したい
• サプライチェーンに関わるチームや業務を、どのような軸で設計するか迷っている
• 倉庫管理や製造現場に特化してきたが、そろそろサプライチェーンの全体像を捉えたい

想定しているのは、コンサルタントの方、あるいはサプライチェーンに関わるチームのマネージャー・部長クラスの方です。

SCORモデルとは

SCORモデルは、Supply Chain Operation Reference Model の略です。Reference Model（参照モデル）という名の通り、サプライチェーンマネジメントの標準的なプロセスやベストプラクティスを参照しながら、自社のSCMの現在地を把握し、あるべきサプライチェーンを描くときに使います。

成り立ちについて、英語版Wikipediaの記述を訳すとこうです。

SCORは、1996年に経営コンサルティング会社のPRTM（現在はPwCの一部）とAMRリサーチ（現在はGartnerの一部）によって開発され、サプライチェーンカウンシル（現在はAPICSの一部）によって承認され、サプライチェーン・マネジメントの業界横断型のデファクトスタンダード、パフォーマンス管理、プロセス改善診断ツールとして使用されています。

この経緯もあってか、ASCMのベンチマーキングサービスであるSCORmarkは、PwCとのアライアンスによって実施されています。

このフレームワークが実用に耐えるのは、Intel・IBM・P&Gといった高水準のSCMを実践する企業とともに検証され、時代に合わせて更新され続けているからです。私が学習していた時点では2017年リリースのSCOR 12.0が最新版でしたが、ESG指標やデジタル化の影響を受けて、2022年に「SCOR DS（Digital Standard）」へ刷新されました。ビジネス環境の変化に応じて改訂され続けていること自体が、このモデルの信頼性を示しています。

この記事では、SCMの全体像を概念的に理解することを目的とするため、CSCP学習当時に作成した資料（2017年版に基づく）をもとに説明します。

実務で導入する場合は、必ず最新版のSCOR DSの公式ドキュメントを参照してください。

全体像と、この記事で扱う範囲

SCORモデルには何が定義されているのか。CSCPのテキストだけでは全体像が掴めず、APICS公式のYouTube、原文資料、海外のブログ記事などを漁りました（日本語の記事は古く、断片的なものが多いのが実情です）。

全体像はおおよそ次のようになります。

SCORモデルには4つの領域が定義されています。

• Process：サプライチェーン上のプロセス、およびプロセス間の関係性の標準
• Performance：サプライチェーンプロセスにおけるパフォーマンスの属性と、標準的な管理指標
• People：プロセスの実行に必要な人材要件の標準
• Practices：パフォーマンス向上のためのプラクティス

これら4領域は、Processを起点に展開します。あるプロセスの成否を測る指標は何か、そのプロセスを遂行するための人材要件は何か、パフォーマンス向上に必要なプラクティスは何か——という形で参照できる構造です。

あくまで標準なので、実際のプロジェクトでは業界や組織ごとにカスタマイズが必要です。それでも、サプライチェーンに関わる人、とりわけマネジメント層にとって、こうした拠り所があるのはありがたいものです。

活用方法についてはこちらの記事が参考になります。Ver.12のローンチ（2017年）以前の記事なので少し古いですが、だいたいのイメージはつくかと思います。

全体像を示したうえで、この記事ではProcessのレベル1のみを扱います。本来はそこだけを書くつもりでしたが、SCORモデルの全体像に触れた記事が見当たらず、私自身が困った経験があるため、併せて共有することにしました。さらに踏み込みたい方向けに、記事の最後に参考URLを載せています。

SCORモデルにみる6つのマネジメント領域

ここからは、SCORモデルの出発点であり最重要箇所でもある、6つのマネジメントプロセスを説明します。まずは、SCMにはこの6領域があることを押さえてください。

APICSのテキストを参考に各プロセスを説明すると、次のようになります。

Plan（計画）

サプライチェーンの運用に関連するプランニングプロセス全般。需要に関する情報収集、供給リソースに関する情報収集、需要と供給のバランシング、需給ギャップの特定、およびギャップを埋めるための各種アクションの計画など。

Source（調達）

調達の実行に関わるプロセス全般。サプライヤーから納入される商品やサービスの発注・スケジューリング・受入など。具体的には、発注書発行、入荷予定調整、受入、出荷確認、材料保管、仕入先からの請求書処理が含まれます。

Make（生産）

生産の実行に関わるプロセス全般。一般的な製造業に見られる材料の加工に加え、サービスに関わるコンテンツ作成などの活動も含みます。組立、化学処理、メンテナンス、修理、分解、リサイクル、改修、再製造など、あらゆる種類の材料の変換を表すため、「生産」や「製造」というよりも、材料が何かに変わることに重点が置かれています。これらのプロセスは一般に、1つ以上の品目番号が入力され、1つ以上の異なる品目番号が出力されるという事実によって識別されます。

Deliver（納入）

納入の実行に関わるプロセス全般。顧客からのオーダーを受注してから、その履行に関連する活動全般を含みます。オーダーの受領、確認、出荷指示の作成、配送スケジュール、ピッキング、梱包、出荷、顧客への請求書発行などです。

Return（返品）

返品の実行に関わるプロセス全般。返品の必要性の確認、対応の決定、返品のスケジュール、返品物の発送と返却が含まれます。なお、修理・リサイクル・改修・再製造のプロセスは、ReturnではなくMakeにあたります。

Enable（業務基盤）

サプライチェーンの運用に必要な情報、リレーション、リソース、資産、ビジネスルール、コンプライアンス、契約などの確立・維持・管理に関連する活動全般。計画・実行プロセスの実現とガバナンスを支援します。

これらの領域は、次のようにも大別されます。

• 計画プロセス：Plan
• 実行プロセス：Source・Make・Deliver・Return
• イネーブルプロセス：Enable

注目したいのは、SCORモデルが標準化にフォーカスしているため、SCMと聞いて思い浮かべる自動車や食品といった製造業だけでなく、映画や電力などのサービス産業にも適用できる点です。各プロセスの説明も、どの業界にも当てはまるように記述されています。実際、SCORモデルは産業界にとどまらず、公共機関や軍事にまで活用されています。

さらに、これらのレベル1プロセスは、組織を超えてサプライチェーンの上流・下流へと広がります。

SCM関連の業務やプロジェクトは、すべてこの図の世界の中で発生しています。私自身の経験で整理すると、新卒コンサル時代に関わった自動車メーカーの間接材購買システム統合プロジェクトはSource・Enableの領域、自動車部品メーカーの工場・物流拠点のBPRはMake・Deliver・Enableの領域、メーカー時代の需給プランニングはPlan・Enableの領域、という具合になります。振り返れば、プロセスレベルではサプライチェーンの全領域に関わってきたことになり、SCORモデルによって過去のキャリアの棚卸しができました。

サプライチェーンに関わる方であれば、ご自身の仕事もこの中のいずれかに位置づけられるはずです。コンサルタントの場合、システム統合やルール設計など、Enable × 他領域のプロジェクトが多いのではないでしょうか。

Lv.1プロセスが活きる場面

サプライチェーン関連の組織設計

この図が頭に入っていると、ロジスティクス部門などのチーム設計に役立ちます。

理想的には、調達（Source / Return）・生産（Make）・物流（Deliver / Return）の各実行部隊があり、需給（Plan）などの計画部隊が別にある形です。生産をOEM、物流を3PLに委託している会社であれば、デマンドプランニング部隊が作成した計画（Plan）をもとに、購買チームがSource／Makeをサプライヤーと調整し、物流チームが3PLや顧客とDeliver／Returnを調整する。EnableはIT部門・法務部・経理部がメインで担うことになります（こことのリレーション構築も、各チーム管理職の重要な仕事です）。どの領域にどんな業務があるかは、SCORモデルのLv.3プロセスで把握できます。

とはいえ、そんなリソースはない、という状況も多いはずです。その場合は、計画プロセスと実行プロセスでチームを分けることを勧めます。

私はメーカーで需給などの計画系業務と、調達・購買といった実行系業務の両方を経験しましたが、この2つは頭の使い方がまったく異なります。前者は意思決定業務、後者は基本的に定型業務です。計画業務に「100%正しい」はあり得ないので、完璧主義者よりも、落とし所を探る思考と、関係者を巻き込むストーリーを語れる能力が重要になります。対して実行業務では、いかにスピーディにミスなく作業を遂行するかが求められます。

リソースが限られる場合、仕入（サプライヤー対応）と出荷（3PL・顧客対応）で分けられがちですが、計画責任の明確化と人材の適正配置という観点から、計画系／実行系での分け方のほうが機能すると考えています。

サプライチェーン成熟度がレベル1の企業では、すべての起点となる計画業務が軽視されがちです。営業やマーケティングの担当者が、数ある業務の隙間時間に当てずっぽうのフォーキャストを作成している、というケースが散見されます。その結果、Source・Make・Deliver・Returnのすべてに支障をきたし、リカバリーに各担当者が追われて1日が終わる。そんな地獄のような光景が繰り広げられることになります。社員の健康のためにも、まずはPlanningチームを作りましょう。

エキスパートインタビュー

スポットコンサルサービスでヒアリング対象者を探すときにも、このフレームワークは役立ちます。

「SCMの専門家」と一言で言っても、ここまで見てきた通り対象領域が広すぎます。どの解像度でヒアリングしたいかにもよりますが、Plan・Source・Make・Deliver・Return・EnableというLv.1プロセスを軸に、対象領域と有識者をマッチングさせるとよいでしょう。さらにProcessのレベルまで合致していれば、ヒアリングの精度は上がります。目安として、Lv.1が部門長や経営層、Lv.2が部長クラス、Lv.3がチームマネージャークラスに対応します。

ここまでProcessのLv.1しか見ていませんが、それでも十分に示唆のあるフレームワークです。Lv.2→Lv.3への展開や、Performance・People・Practicesの内容も学びが深いので、後段の参考URLもぜひ覗いてみてください。

SCORモデルが定義していること・いないこと

最後に、スコープに関する重要な点を挙げておきます（CSCPテキストより私訳）。

適用される活動

• オーダー入力から支払までの、すべての顧客とのやりとり
• 機器・スペアパーツ・バルク製品・ソフトウェアなどを含む、すべての製品取引（物理的な材料やサービス）
• 総需要の把握からフルフィルメントに至るまでの、すべての市場とのインタラクション

適用されないプロセス

• 営業・マーケティング（需要創出）
• 研究・技術開発
• 製品開発
• 納品後のカスタマーサポートの一部（ただし、基本プロセスとして返品を含む）

イメージとしては、量産品として回り出してからの運用に適用される、と捉えて差し支えありません。ただし実際には、量産で回っているときよりも、開発時期や廃盤決定後の運用に悩みを抱えている会社のほうが多いはずです。その意味では、惜しさも残ります。

私自身の問題意識として、開発段階におけるサプライチェーン部隊（Businessサイド）とプロダクト部隊（Designサイド）のコラボレーション欠如を強く感じています。それが結果的に大量生産・大量廃棄を引き起こし、事業と地球の双方に大きな負荷を与えています。

Xcraftは、このプロダクト開発とサプライチェーンのあいだを橋渡しすることで、企業の枠を超えたエコシステム全体を美しくデザインする役割を担いたいと考えています。

より深く学びたい方へ

想像以上のボリュームになりましたが、ここまで読んでいただきありがとうございます。最後に参考資料を挙げておきます。

• 「知識ゼロで理解するサプライチェーンマネジメントと業務改善」連載一覧｜2008年の連載でかなり古いものの、日本語の記事では最も噛み砕かれていて分かりやすい。
• SCOR DS（Digital Standard）｜最新版のSCORモデル。
• SCOR DS / SCOR 12 Comparison Document｜最新版のSCOR DSと、この記事で参照したSCOR 12の比較。Make → Transform、Enable → Orchestrateへと名称が変わり、Deliver → Order／Fulfillに分割され、Processは計7領域になっています。
• SCORモデルを使ってSCMの基礎的理解を得るためのFree Course｜新しく開講されていますが、私はまだ受講していません。

なお、SCOR Professionalというエンドースメントは2023年12月末で終了し、現在はCTSC（Certified in Transformation for Supply Chain）モジュールで一部内容が提供されています。いつか取得したいところです。