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

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


こんにちは。ミカドです。

今回も、前回に引き続き日本ではあまり知られていない有用なSCMフレームワークについて書きます。その名もSCORモデル。(略語ではスコアと読みます。恥ずかしながら、ずっとエスシーオーアールモデルだと思っていました。。)

本記事は下記のようなお悩みをお持ちの方にとっては、少しはお役に立てるかと思います。

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

そんな悩みを持ったコンサルタントの方やサプライチェーンに関わるチームのマネージャーや部長クラスの方を想定しています。

その他SCMプロジェクトに使えるフレームワークをお探しの方は、先日執筆した【SCMフレームワーク】サプライチェーン成熟度の4ステージも参考になるかと思いますので是非ご一読ください。


SCORモデルとは(概説)


まずは中身に入る前にこのフレームワークについてざっくり概要を述べます。まず、SCORモデルとは、Supply Chain Operation Reference Modelの頭文字をとった略語です。Reference Model(参照モデル)とある通り、サプライチェーンマネジメントにおける標準的なプロセスやベストプラクティス等を参照しながら、自社におけるSCMの現在地を把握し、あるべきサプライチェーンを描く時に使えるフレームワークです。

以下、Wikipedia情報より筆者訳。

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

このような歴史からか、SCORmarkというASCMのベンチマーキングサービスはPwCとのアライアンスによって実施されています。

そしてこのフレームワークが活用できるものである所以は、Intel・IBM・P&GといったハイレベルなSCMを実践する名だたる企業と共に検証され、時代に合わせてアップデートされ続けている点です。現在の最新版は2017年にリリースされたSCOR 12.0ですが、サーキュラーデザインやDtoCなどNewトレンドの台頭を受けて近いうちにまた改良されるのではないかと思います。

理論だけでなく、現場からのフィードバックを受けて進化し続けるという性格が、長年世界のトップ企業に活用され続ける有用性を生み出しているのでしょう。


SCORモデルの全体像と本記事のスコープ


さて、そんなSCORモデルですが、どのようなことが定義されているのでしょうか。CSCPだけではイマイチ全体像が把握できず、APICS公式Youtubeやら原文資料、その他海外ブログ等を漁ってみました。(日本語での記事は古くて限定的なものが多かった。。)

全体像としてはおおよそこんなイメージ。

SCORモデルの全体像

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

Process
サプライチェーン上のプロセスおよびプロセスの関係性についての標準を定義

Performance
サプライチェーンプロセスにおけるパフォーマンスの属性と標準的な管理指標を定義

People
サプライチェーンプロセス実行に必要な人材要件についての標準を定義

Practices
サプライチェーンプロセスにおけるパフォーマンス向上のためのプラクティスを定義

これらの各領域がProcessを起点として展開されていきます。このプロセスの成否を測る指標は〇〇で、そのプロセスを遂行するための人材要件は△△で、パフォーマンス向上に必要なプラクティスは□□、といった具合に参照できます。あくまで標準なので、実際プロジェクトを推進する際は業界や組織ごとにカスタマイズが必要ですが、サプライチェーンに関わる人(とりわけマネジメント層)にとってこのような拠り所があるというのはありがたいですよね。

SCORモデル要素の関係性

活用方法についてはこちらの記事が参考になります。Ver.12のローンチ(2017年)以前の記事なので少し古いですが、だいたいのイメージはつくかと思います。近いうちに本ブログでも活用イメージについて書きます。(多分・・・)

なお、CSCPで触れられているのはProcessとPerformance(の触り)のみなので、より深く広く学習したい方はSCOR-P(SCOR-Professional)の取得をおすすめします。CSCPやCPIMよりも安くて学習範囲も限られているのでおすすめです。私自身、大学院卒業後にでも取得できたらな〜と考えている次第です。

そしてなんと、これだけ前置きしておきながら本記事ではProcessのレベル1についてのみ触れます。本来はそこだけ記事にしようと思っていたのですが、このようなSCORの世界観について書いている記事があまりなくて自分自身も困っていたので、ここは合わせてお伝えしておきたかったというわけです。最後に参考URLを載せておきますので、さらに踏み込みたい方はそちらからどうぞ。本ブログでも後日続きは書く予定です。


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


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

SCORモデルLv.1プロセス

APICSを参考に各プロセスを説明すると、おおよそ下記のようなところです。

Plan(計画)

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

Source(調達)

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

Make(生産)

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

Deliver(納入)

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

Return(返品)

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

Enable(業務基盤)

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

またこれらの領域は下記のようにも大別されます。

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

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

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

SCORモデルProcessのスコープ

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

皆さんが関わられている仕事もこの中のいずれかではないでしょうか? コンサルタントの方はシステム統合やルール設計などEnable × その他いずれかの領域だと思います。


SCORモデルLv.1プロセスが活躍しそうな場面


そしてこの図が頭に入っていると、ロジスティクス部門などのチーム設計にも役立ちます。理想的には、調達(Source / Return)・生産(Make)・物流(Deliver / Return)の各実行部隊がいて、需給(Plan)などの計画部隊が別で欲しいところです。生産はOEM、物流は3PLに委託しているような会社では、需給部隊が作成した計画(Plan)をもとに購買(仕入etc.)チームがSource・Makeをサプライヤーと調整し、物流(出荷etc.)チームが3PLや顧客とDeliver・Returnの調整をするというのが理想的です。EnableはIT部門や法務部、経理部がメインで担うことになるでしょう(こことのリレーション構築も各チームマネージャーの重要な仕事)。実際にどの領域にどのような業務があるのかは、SCORモデルのLv.3プロセスにて把握できます。最後のリンクをご参照ください。

とはいえ、そんなリソースはない!ということも容易に理解できます。そのような場合は、計画プロセス・実行プロセスでチームを分けてみてはどうでしょうか。私自身メーカーにて需給などの計画系業務の他、調達・購買といった実行系業務のどちらも経験しましたが、これらの業務では基本的に脳みその使い方が全く異なります。前者は意思決定業務であり、後者は基本的には定型業務です。計画業務では「100%正しい」はあり得ないので、完璧主義者よりも、落とし所的思考と関係者を丸め込むストーリーを語れる能力が重要です。対して実行業務では、いかにスピーディーにミスなく100%の作業を遂行するかが求められます。リソースがない場合、仕入と出荷などに分けられがちですが、計画責任の明確化・人材の適正配置の観点から、個人的には計画と実行というチーム分けが正しいと思います。

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

他にも、ビザスクなどのスポットコンサルサービスでヒアリング対象者を探すときにもこのフレームは一役買ってくれるでしょう。「SCMの専門家」と言いますが、ここまででお分かりの通り、対象領域が広すぎます。どんな解像度でヒアリングを行いたいかにもよりますが、1つの軸として、Plan・Source・Make・Deliver・Return・EnableのSCORモデルLv.1プロセスを使って自身の担当領域と有識者のマッチングを図るのがよいのではないでしょうか。更に言えば、Processレベルまでマッチしていると高いヒアリング効果が期待できるでしょう。おおよそProcessのLv.1が部門長や経営層、Lv.2が部長クラス、Lv.3がチームマネージャークラスのはずです。

とまあ、まだProcessのLv.1しか見ていないのですが、すでに示唆に富んだフレームワークな匂いがしてきましたね。Lv.2→Lv.3への展開、Performance・People・Practiceについても追って触れたいところです。


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


最後に、SCORモデルのスコープに関して重要な点をいくつか挙げておきます。(以下、CSCPテキストより筆者訳)

SCOR Version 12.0は、以下の活動に適用されます。

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

SCOR Version 12.0は、以下のプロセスには適用されません。

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

これらのスコープ外のものについても同様の標準があるようですが、アップデートされていないようです。「Association for Supply Chain Management(APICS)」というくらいなので、サプライチェーンに照準を絞ったSCORモデルさえメンテナンスし続けてくれれば十分ですが。

イメージとしては、量産品として回り出してからの運用に適用されると捉えていて差し支えないと思います。実際は量産品として回転している時より、開発時期や廃盤決定後の運用に悩みを抱えている会社も多いですよね。そういう意味では、若干の惜しさも残っています。個人的問題意識として、開発段階でのサプライチェーン(Business)とDesignのコラボレーションの欠如を強く実感しています。それらが結果的に大量生産・大量廃棄を引き起こし、ビジネスと地球に多大なダメージを与えています。デザインスクール卒業後は、この辺りの、開発とSCMのブリッジをしていける人間になりたいな〜と思ったり思わなかったりしているとのやんわり決意を披瀝したところで、本日はお開きにします。


Appendix:SCORモデルをより深く学びたい方


2000文字程度で書く予定が、想像以上のボリュームになってしまいました。。ここまで懲りずに読んでいただいた方、ありがとうございます。

最後にもっと学びたい人向けに、参考資料やURLを貼っておきます。

「知識ゼロで理解するサプライチェーンマネジメントと業務改善」連載一覧
連載が2008年とかなり古いですが、日本語の記事だとこちらが一番噛み砕かれていて分かりやすいです。

QUICK REFERENCE GUIDE
本家の資料(SCOR Ver.12)がなんと、1096ページというモンスターPDFです。とてもじゃないけど読みきれません。。そして発見しました。冒頭で挙げたようなお悩み解決が目的ならこの4ページで十分こと足ります。

SCOR Ver.12 Introduction
サクッと全体像を把握したいならこちら。

SCOR-P
プロフェッショナルを目指すぜ!って方、是非ともチャレンジしてみてください。

それでは、また。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です