SCMに取り組むすべての企業のために

ザイオネックスでは、SaaS型SCMシステム「PlanNEL（プランネル）」の提供だけではなく、SCM（サプライチェーンマネジメント）に関連するセミナーも開催しております。今回は、2025年7月17日(木)に開催した「失敗事例から学ぶ、SCMプロジェクトの始め方セミナー」のレポートを公開いたします。

国際紛争や政治的対立などにより、将来の見通しがますます不透明になる中、経営環境の変化に迅速に対応し、持続的な成長を実現するために、SCMに取り組もうとする企業が増えています。

しかし、社内で初めてSCMに取り組むケースでは、「何から始めるべきか分からない」「関係部署との合意形成が難しい」など、さまざまな壁に直面するのが実情です。

そこで、本セミナーでは、「SCMは組織にとって、どのような位置付けで、どのような役割を果たすのか」「プロジェクトを始めるにあたって、社内でどのように合意形成を図るべきか」「ありがちな失敗と、その回避する方法」など、初めてのSCMプロジェクトにおいて押さえるべきポイントを、具体的な事例とともにご紹介いたします。

SCM仕組み構築の難しさ

ザイオネックス　代表取締役　藤原：
SCMの仕組みは、いきなりシステムを導入するのではなく、背景にはさまざまな課題や問題意識があるはずです。そうした中で、SCMの仕組みを検討する企業が多いのではないでしょうか。本日は、まだそうした仕組みが整備されていない企業の皆さまに向けて、お話をさせていただきます。

図であげているのは一般的なお悩みでして「将来の需要が見えない」「Excelでさまざまな計画表を作っているが限界」「工場で生産過剰・在庫過多」などのケースがよく聞かれます。

最近では地政学リスクの影響もあり、工場や在庫拠点の移転など、サプライチェーンの構造を見直す動きもあるでしょう。こうした変化に対して、手作業だけで対応するのは、ますます困難になってきています。

少しシステム面に触れますと、多くの企業ではSalesforceやExcel、基幹システムなど、さまざまなツールを活用してSCM領域を担っていると思います。しかし、個別のツールごとにデータが分断されてしまい、業務が煩雑になってしまうといった課題もよく見受けられます。

こうした背景の中で、SCMの仕組み作りがいかに難しいかという声を、よくお聞きします。もちろん会計システムや基幹システムの構築も簡単ではありませんが、それ以上にSCMの仕組み作りは難易度が高いと言われています。

その理由として、ここでは7つのポイントをあげています。

まず1つ目は「関係者の多さ」です。SCMは営業、調達、生産など、社内のさまざまな部門が関わります。それぞれの部門には「コスト削減」「品質向上」など異なる目的があり、その調整が非常に難しくなるのです。

2つ目は「情報の可視化・共有の難しさ」です。正確な在庫情報などの実行系データは必要不可欠ですが、それらをリアルタイムで把握して共有する仕組みが整っていない企業も少なくありません。AIを用いた需要予測も進化していますが、実行系の情報と連携できないと精度も下がってしまいます。また、自社単独での対応では限界があり、取引先など企業間での連携がなければ、全体最適にはつながりません。

3つ目は「需要予測の不確実性」です。市場の変化が激しく、社会情勢も日々変わる中で、将来の需要を正確に予測することは非常に難しくなっています。国際情勢や経済リスクなど、予測不能な事象も多く発生しています。

4つ目は「業務プロセスやシステム統合の難しさ」です。小規模な企業であれば全体像を把握しやすいかもしれませんが、大企業になると部署や事業が多岐にわたり、「どこで何の業務が行われていて、どのシステムが使われているのか」を誰も全体像を把握できていない、というケースが多くあります。

5つ目は「グローバル化に伴うリスクの増加」です。たとえば、トランプ政権時代の関税政策のようなものや、近年では戦争・紛争など地政学的リスクが顕在化しています。これらの影響で、調達や供給、在庫拠点の再編を余儀なくされることも増えており、サプライチェーンの柔軟性が一層求められています。

6つ目は「SCMに対する理解不足」です。これも非常に大きな課題の一つだと感じています。たとえば「SCM＝物流のこと」だと思っている方も、まだ多くいらっしゃいます。また、経営層の中には、そもそもサプライチェーンに大きな課題があるとは認識していないケースも見受けられます。

そして最後の7つ目は「柔軟性と効率性のトレードオフ」の問題です。何でも柔軟に対応しようとすると、どうしても効率性が損なわれてしまうというジレンマがあります。

これらの課題を解決していくにあたり、大きく分けて2つの方向性があると考えています。一つはプロジェクトの取り組みで対応できること。もう一つは、ITを活用しなければ対応できないことです。

ここから先は、特にプロジェクトとして取り組むべきポイントに焦点を当ててお話ししていきたいと思います。

取り上げたいのは次の3点です。
・関係者が多く利害が複雑であること（課題①）
・業務プロセスやシステム統合が困難であること（課題④）
・サプライチェーンに対する理解が不十分であること（課題⑥）

まず、サプライチェーンマネジメントの仕組み構築における難しさとして、「関係者が多く、利害関係が複雑である」という点があげられます。

ここに示したように、営業担当、営業アシスタント、購買部、生産、物流、事業部長など、非常に多くの関係者が関わっており、それぞれが異なる目的や役割を持っています。そして、どの業務もサプライチェーンの前段階の情報やプロセスの影響を受けるため、「自分の業務だけでは完結しない」という特徴があります。

サプライチェーンの流れがスムーズでない場合、個別業務の遂行が難しくなり、前工程の情報や状態が阻害要因になることもあります。

たとえば、営業部門は「お客様にすぐ対応できるよう、在庫を潤沢に持っておいてほしい」と考えますが、調達部門や財務部門は「在庫は極力抑えたい」と考える。こういった部門間のギャップが、SCM構築の難しさを生む大きな要因となっているのです。

この図の中に「個別最適なKPI」と書いていますが、ここで言う「個別最適」は必ずしも良い意味ではありません。むしろ、問題として捉えていただきたいポイントです。

部門ごとにKPIが定められていて、それぞれのKPIを達成することが部門としての評価基準になっています。しかし、それが全社的な視点で見たときに、本当に全体最適につながっているかどうかは、一度立ち止まって考える必要があると思います。

そして、SCM構築におけるもう一つの大きな課題が、「業務プロセスやシステム統合の困難さ」です。

よくお聞きするのが、企業の成り立ちや事業形態によって、サプライチェーンの仕組みを統一するのが難しいという話です。たとえば、国内だけでも複数の事業部があり、それぞれの事業部に特徴があります。BtoBを展開している部門もあれば、BtoCを展開している部門もありますし、両方を展開している部門もあります。そうなると、事業の性質に応じてサプライチェーンの仕組みも異なってくるため、完全な統一は難しくなります。

販売・購買・会計といった実効系の業務については、最終的に会計情報へとつながるため、ERPによって統合されているという企業も多いでしょう。特に、日本本社が新設した子会社などでは、最初からERPを統一して導入しているケースが見られます。

一方で、海外のパートナー企業を買収して子会社化したような場合には、導入されているERPそのものが異なっていたり、同じERPでも設定内容やカスタマイズの仕様がまったく異なっていたりすることが多々あります。

また、もともと部品を供給していたサプライヤー企業を買収して自社工場としたケースでも、異なるERPが稼働しているというケースは珍しくありません。

このように、実績系のシステムですら一貫性を保つのが難しい中で、計画系のシステムになると、各部門や拠点が独自の方法で運用していることが多く見受けられます。

こうした背景もあって、最近ではDX推進室やSCM部門が立ち上がり、統一的な仕組みの検討が進められていますが、実際には「どこで何がどのように行われているか」が可視化されておらず、統合の議論ができない、あるいは一気に進めることができない、といった声も多く聞きます。

次に、「サプライチェーンに対する理解不足」について触れたいと思います。
ここに「7つの誤解」という形で代表的なものをあげてみました。

まず誤解1：「SCMは物流の話である」。
本日のセミナーにご参加いただいている皆さんの中には、そういった認識の方は少ないと思いますが、一部の経営者や、SCMにあまり関心がない方の中には、いまだに「物流の最適化＝SCM」と捉えているケースも見受けられます。

続いて誤解2：「在庫を多く持てば問題は起きない」。
特に営業部門の方に多い考え方ですが、欠品リスクを恐れるあまり、「在庫は多ければ多いほど良い」と思われがちですが、在庫過多はコストの増加や廃棄リスクにもつながります。

誤解3：「自部門さえうまく回れば良い」。
部門間の連携が不足している企業では、こうした考え方が根付いてしまっていることもあります。先ほど触れたように、それぞれが個別KPIを追求すると、全体最適が崩れてしまうという問題にもつながります。

誤解4：「SCMはITシステムを導入すれば解決する」。
一部では、ITシステムを導入すればSCMの課題が解決すると考えている方もいますが、これは誤解です。ITシステムはあくまで“手段”であり、“目的”ではありません。SCMにおいて本質的に重要なのは、プロセス設計・情報共有・組織間の調整です。仮にプロジェクトがうまくいかなかった場合でも、それは必ずしもITシステムのせいとは限りません。

誤解5：「需要変動はどうしようもない」。
「需要予測なんて無意味」「どうせ当たらない」といった声も時折耳にしますが、これも大きな誤解です。たしかに、予測が難しい時代ではありますが、将来どのくらい商品・製品が必要とされるかを見込むことは、SCMの起点であり、非常に重要です。

そして、その予測は営業部門だけが立てられるものではありません。販促やプロモーション活動も含めた、さまざまな部門の知見やデータを活用しながら、より精度の高い計画を立てていく工夫が求められます。

誤解6：「サプライヤーや顧客との情報共有はリスクである」。
この点は非常に難しい問題だと思っています。たとえば「自社がどれくらい在庫を持っているかをサプライヤーに開示するのはリスクだ」と考える企業があります。しかし、そのように情報を閉ざしてしまうと、サプライヤー側は将来どのくらい供給すべきかが分からず、結果として供給の安定性が損なわれる恐れがあります。

理想はセキュリティを担保したうえで、戦略的に情報を共有していくことが、リードタイムの短縮や欠品リスクの低減につながります。

これはサプライヤーに限らず、顧客との関係においても同様です。たとえば、顧客が保有する在庫情報を把握することができれば、来月・再来月・さらにその先にどれくらいの供給・出荷が必要になるかといった予測も可能になり、より安定した供給体制の構築につながります。ですので、「将来に向けた情報の共有」として捉えていただきたいポイントです。

誤解7：「SCMの効果はすぐに数字に表れる」。
SCM改革に取り組んだ結果、システムも導入した。だからといって、すぐに来月から成果が見えるかというと、そう単純ではありません。

たとえば、在庫を調整するにしても、調達にはリードタイムがあります。特に海外からの輸入であれば、発注から納品まで1〜2か月以上かかることもあります。そのため、仕組みを変えてもすぐに在庫が減る・改善されるというわけにはいきません。

このように、SCMの取り組みは「調整ごと」であり、効果が現れるまでには一定の時間がかかるということを、あらかじめ理解しておくことが重要です。

以上のような「よくある誤解」に起因して、さまざまな失敗が起きています。

SCM仕組み構築の失敗事例

ここからは、その代表的な失敗事例をご紹介します。これは弊社の事例というわけではなく、他社で実際に起きたことをベースに情報を整理したものです。

まず事例1としてあげるのは、ある大手家電メーカーA社のケースです。複数の生産ラインを持つA社では、「在庫削減」と「納期に対する安定供給」の両立を目指して、サプライチェーンの最適化プロジェクトがスタートしました。

ここで大きな問題となったのが、関係者の多さです。A社は大手家電メーカーであり、組織の規模も大きく、関係部門や関係者の数が非常に多かったのです。

たとえば営業部と生産部では、それぞれの利害関係が異なります。営業部門は「販売機会の最大化」を重視するのに対し、生産部門は「効率的なロット生産」や「コスト削減」を重視します。そのため、営業側から急な計画変更や小ロットの発注があると、生産側は嫌がるという対立構造が生まれていました。

さらに、経営企画部と各事業部の間にもギャップがありました。経営企画部としては、事業部が異なっていてもKPIを統一して、全社最適を目指そうとしましたが、各事業部は異なる特徴や方針を持っており、「自部門の成果を上げたい」という思いが強く、経営企画部が標準化した統一ルールへの反発がありました。

つまり、いくら経営企画側で標準化した管理方法やルールを導入しようとしても、現場の理解や納得が得られず、実行が困難だったのです。

このように、仮に同じSCMシステムを導入したとしても、事業部ごとの業務特性や文化、価値観を無視して一律にルールを押し付けることはうまくいきません。むしろ、各事業部の特徴を尊重しつつ、ある程度の自由度を持たせた設計が重要です。

ただし、会社の経営に直接関わる全社的なKPIやガバナンスに関わる要素については、一定の標準化が必要です。このバランスをどう取るかが、日本企業にとって大きな課題のひとつではないかと感じています。

また、よく見られるのが「IT部門と現場部門の対立」です。

IT部門は、先ほどの経営企画部と同様に、システムの標準化や自動化を重視します。一方で、実際に現場に足を運ぶと「柔軟に運用したい」といった実態があり、システム化と現場運用とのギャップが生じがちです。

そこで、現場に寄りすぎて過剰なカスタマイズや追加開発を行ってしまうと、当然ながら導入コストが膨らんでしまいます。

このA社でも同様のことが起きました。結果として、在庫削減は実現できず、むしろ「安全在庫を増やそう」という方針に転換されました。

しかし、すべての品目で安全在庫を確保することはできず、急激に需要が伸びた品目や、受注が集中した商品については欠品が発生し、納期遅延に至ってしまいました。

最終的に、SCMシステムの導入には大きなコストをかけたにもかかわらず、十分な投資対効果は得られない結果となってしまいました。

この事例から得られる教訓として、SCMを単なるITの問題、あるいは在庫管理の話と捉えてしまうと、本質を見誤ってしまうという点があげられます。

サプライチェーン改革においては、部門間の対立や価値観の違いを乗り越える「全社的な意識改革」、そして「十分な合意形成」が必要です。

どうしても「全体最適」と「部分最適」は対立します。そのため、トップダウンでの強いリーダーシップと、現場との丁寧な調和が不可欠だということが、この事例の本質です。

ここからは、失敗事例の2つ目をご紹介します。

電子部品メーカーのB社では、調達担当者がExcelを使ってPSI表を手作業で作成していました。基幹システムから実績データを取り出し、それをもとに数字を調整しながら、発注数量や生産依頼数を決めていました。

しかし、販売拠点や在庫拠点の増加、扱う品目の多様化などにより、Excelではもう対応しきれなくなり、「そろそろ限界だ」ということで、SCMシステムの導入が決まりました。

ところが、このプロジェクトは「調達担当者のPSI表を何とかしよう」という現場の課題感からスタートしたもので、スコープが狭く、「全社的にどう変えていくか」という視点が欠けていました。

経営層はプロジェクトの立ち上げ自体には承認を出していたものの、実態としては「調達部門の業務改善」レベルの話として進んでしまい、結果的に「従来のExcelベースの業務をそのままシステム化する」という方針で、調達担当者のやり方に沿ったカスタマイズが多く行われました。

当然、それによって導入コストは増加しましたし、そのカスタマイズが本当に合理的だったのか、疑問が残る形となってしまいました。

もう一つの大きな問題としてあげられるのは、「このプロジェクトがITプロジェクトとして位置づけられてしまっていた」という点です。

IT部門が主導し、導入ベンダーとともにプロジェクトを進めていきました。要件定義についても、現場担当者へのヒアリングだけで構成され、最終的な要件定義書の承認も現場のマネージャーが行っていました。

つまり、「このシステムから得られるアウトプットを、オペレーションの現場でどう活用するか」は考えられていたものの、「それを経営の意思決定にどう生かすか」という視点が完全に抜け落ちていたのです。本来であれば、システムが出力する情報は、経営指標や戦略的な判断材料として活用されるべきです。

しかし、プロジェクト当初から経営層がこの取り組みに対して無関心であり、投資対効果の検討も不十分だったため、「経営の意思決定にとって価値あるアウトプット」が得られないまま、単なる業務改善レベルで終わってしまったのです。

その結果、導入と運用にかかった大きなコストに対して、十分な効果を得ることはできませんでした。

この事例から得られる教訓は、「システム導入を経営としてどう活用していくか」という視点を、最初から明確に持っておく必要があるということです。

SCM業務そのものがまだ標準化・組織横断で実行されていない段階で、いきなり大規模なIT投資を行うことには大きなリスクがあります。そのため、段階的に拡張可能な設計にする、小さく始めて成果を見ながら徐々に広げていく、といったアプローチの方が適していたのではないかと考えられます。

3つ目の失敗事例は、ある食品メーカーC社のケースです。

C社は大手メーカーが企画した商品を自社工場で受託製造する、いわゆるOEM型のビジネスを行っている企業です。社長交代をきっかけに、「SCM経営」というコンセプトが社内で大きく打ち出され、取り組みが本格的に始まりました。

まずIT部門が情報収集を行い、SCMシステムを新たに導入するという選択肢もあったのですが、すでに社内にあるSFAやBIツールを活用・拡張すれば、目的は達成できるのではないか、という判断になりました。

受託製造型企業の製造においては「どのように作るか」がより重要となるため、生産スケジューラは新規導入することになりました。

こうしてプロジェクトは始まり、SFAでは営業担当が登録する商談情報や販売見込みを活用して、販売計画を生産計画につなげる構想が立てられました。そして、SFAに毎月の販売計画を入力できるようにシステムを改修しました。

しかし、既存の商談情報、新たな販売計画、基幹システムで管理されている受注データとの関係やルールの明確化がなされないまま進めたため、営業担当者にとって「何をどこまで入力すべきか」が不明確となり、全営業に対して毎月販売計画を正しく入力させるのが難しくなってしまいました。

また、BIツールについても、基幹システムの実績データとSFAに登録された情報を組み合わせれば、「実績 vs 計画」の比較や進捗のチャート化などが可能になる予定でしたが、現実にはSFAが十分に活用されておらず、データが揃わなかったため、BIツールによる分析や可視化も構想どおりには実現できませんでした。

一方で、生産スケジューラについては新たに導入され、スケジューラ単体として「素早い生産調整」は可能になったという点では一定の効果があったようですが、繰り返される受注変更に対して運用が追いつかないという問題が発生しました。

また、実際に運用してみると、原材料や資材の調達にかかるリードタイムが想定よりも長く、受注を受けてから生産スケジューラを回して資材所要量計算を行ったのでは間に合わないという現実が明らかになったのです。その結果として、少なくとも半年先を見据えた販売計画や生産依頼予定がなければ、原材料の調達が間に合わず、結局「生産ができない」という事態に陥ってしまいました。

そもそも、このプロジェクトは「既存のSFAやBIを拡張すれば何とかなるだろう」という構想から始まったため、IT部門主導で進められ、業務プロセスやルールの明確な定義が行われませんでした。

その結果、さまざまな運用シナリオを想定した全体設計になっておらず、実際の業務に合わないシステムが出来上がってしまい、利用されなくなってしまったのです。いわば、最悪のケースとなってしまいました。

この事例から得られる教訓は、「既存の社内システムを拡張し、カスタマイズしてSCMの機能を実現しようとする場合、それには相応のリスクがある」という点です。

もともとSCMを前提に設計された機能が備わっていないシステムに対して拡張を加えるには、丁寧な業務設計とシステム設計が必要になります。そのためには、十分な時間とリソースをかけて準備する必要があったと考えます。

SCM仕組み構築の失敗事例の教訓から何を学ぶか？

そして、教訓から何を学ぶかですが、やはり、SCMの仕組み構築は一筋縄ではいかない、難しい取り組みだということを、このような失敗事例が如実に物語っています。

こうした失敗を克服するためには、どうすればよいのでしょうか。

私自身も長年、生産管理システムやサプライチェーン系のシステム構築に携わってきましたが、うまくいったと感じたプロジェクトには共通点があります。

それは、経営層から「SCMの仕組みを導入する」という明確な意思表明がなされ、プロジェクト開始前に部署間で課題を共有する場が設けられていたことです。これが、成功の大きな要因だったと思っています。

たとえば、図にあげているような「ワークショップ形式」の取り組みがあります。私も過去にファシリテーターとして何度か関わらせていただきました。

1日、あるいは半日など、ある程度まとまった時間をとって、同じ空間に関係部署の方々が集まり、お互いの課題や悩みを率直に出し合う場を設けるのです。そうすると、「自分の部署だけが困っているわけではない」「あの部署も同じような悩みを抱えていたんだ」といった共感が生まれます。

これにより、対立構造ではなく、協力関係が芽生えるようになります。これはSCMに限らず、あらゆるプロジェクトを円滑に進めるうえで、非常に重要なステップです。

ただし、こうした取り組みを社内メンバーだけで進めようとすると、なかなかうまくいかないこともあります。そこで、第三者をファシリテーターとして活用して、中立的な立場で議論を整理するのが効果的だと感じています。

また、「業務プロセスとシステムをどう統合するか」という課題に対しては、「業務とITのマッピング」を活用することが有効です。

私がこれまでよく行ってきた方法として、まず現場をしっかり調査・観察し、「どの業務に、どのシステムが使われているのか」を可視化していきます。

たとえば、ある事業部では特定のERPを使っていて、別の事業部では買収で加わった会社のERPがそのまま使われている、といったこともよくあります。

このように、組織の実態を正確に把握したうえで業務とシステムを結びつけて整理することが、最初の一歩として非常に重要です。

これはあくまで一例ではありますが、まずは「大きなレベル」で業務全体を把握するところから始めます。ここでは、「Excel」や「基幹システム」などといった箱（業務名・システム）で表していますが、実際には、より細かなレベルでさまざまなシステムが使われていることもあります。

たとえば、「月次販売計画」と一言で言っても、実際の業務はもっと細かく分解されているケースがあります。そうした分解された業務単位に対して、それぞれどのシステムが使われているかをマッピングしていくことが非常に有効です。ここで大事なのは、「どういう軸でマッピングを行うか」です。

ここでは仮に「A事業部」「B事業部」「C事業部」というように事業部単位で整理していますが、必ずしもどの企業でも事業部が最適な単位とは限りません。企業によっては、「製品カテゴリ別」に業務プロセスや計画の立て方が良い場合もあります。

あるアパレル企業では、「売れ筋商品」は毎日のように販売実績が更新されるため、月次の計画では不十分であり、週次で需要計画と調達計画を立てる必要がある、というケースがありました。

一方で、同じアパレル企業であっても「ベルト」のように大量に売れない商品であれば、月次での計画でも十分です。このように、同じ企業内でも製品カテゴリによって最適な計画頻度や粒度が異なるのです。

したがって、こうした特性を考慮に入れて「業務×ITマップ」を作成することが、非常に重要なポイントになります。

単に組織単位で整理するのではなく、「どのような業務が、どの頻度で、どの対象に対して行われるのか」といった観点を持つことが、成功につながるマッピングのコツだと考えています。

もうひとつ大事なポイントとして、「SCM業務における共通の枠組みを持つこと」があげられます。これは非常に重要です。

紹介している図は、「SCMがどのような業務機能で構成されているか」を整理したもので、私たちがよく使っているものです。

まず大前提として、SCMの「M」はマネジメントです。つまり、PDCAのように「計画」と「実績」を回していくことが基本になります。

そのためには、まず土台となる「実行系の機能」が必要です。
この実行系というのは、どの企業でもすでに取り組まれている部分だと思います。

たとえば、
・受注を登録する
・販売が行われた
・納期が設定された
・在庫がどれだけあるか把握している
といった情報です。

これらの実績・実行系のデータは、ERPなどの基幹システムで管理されている企業が多いかと思います。

一方で、私たちがご支援することが多いのが、その上にある「計画系」「評価」の領域です。ここを「SCP（サプライチェーンプランニング）」と呼んでいます。

しかし、この「計画系」の領域については、多くの企業で共通の枠組みがしっかりと定義されていないケースが多いと感じています。

この計画系は、大きく「需要計画」と「供給計画」の2つに分けて考えるとわかりやすいです。

たとえば、「需要」とは将来の販売見込みです。その中には、以下のような計画が含まれます。
・年次や月次の予算計画
・機械的に算出される需要予測
・営業部門など、販売を担当する部門が立てる販売計画

こうした「需要計画」を起点として、今度は「どれだけ在庫を持つべきか？」「安全在庫の基準はどうするか？」「補充のタイミングや発注量はどうするか？」といった「供給側の計画」が連動してきます。

さらに、その在庫補充の計画を前提に、「工場で本当に生産が間に合うのか？」という、いわゆる大きな粒度での供給計画を立てていきます。

このように、計画系の業務は
・需要計画（予算計画、需要予測、販売計画）
・供給計画（在庫計画、補充計画、需給計画）
という2つの柱で構成されていることを共通理解として持つことが大切です。

この枠組みに沿って社内で会話をしていくことで、自分たちがどの領域に対してどんな業務をしているのか、整理がしやすくなりますし、部門間の認識のズレも減らすことができます。

評価の領域についてですが、多くの企業ではBIツールなどを使って取り組まれていると思います。

もちろん、ERPにも評価やレポート、ダッシュボードの機能が備わっている場合もあります。ただし、言えるのは、「将来の計画」と「実績」との比較や整合といった観点が、まだ十分にカバーされていないケースがあるということです。この部分をしっかり補完していくのが、いわゆるS&OP（Sales and Operations Planning）の領域になります。

次に、プロジェクトの進め方についてお話しします。ここも非常に重要なポイントです。

課題が見つかったから、場当たり的に課題解決に向けて取り組むと失敗することがあります。そうならないためには、先ほど紹介したようなワークショップで抽出した課題とその解決策を、「どのようなロードマップで実現していくのか」を整理しておくことが重要です。

こうした整理は、「コンサルタントに頼まなければできない」と思われるかもしれませんが、実は自社内でもここに示すような枠組みを使っていただければ進めることは可能です。

たとえば、以下のような視点で構成された枠組みでプロジェクトを設計してみると良いでしょう。
・目標は何か
・どのような取り組みを行うのか
・誰が関係者なのか（関係部門、担当者）
・どの業務をどのようにシステム化するのか
・期待される効果は何か
・その成果をどう評価するか

こうしたポイントを整理したうえで、段階的にプロジェクトを進めることで、より実行可能性の高い構想になります。

そして、プロジェクト推進においてもう一つ重要な点があります。それは、「人を無視したシステム導入は絶対にしないこと」です。

責任範囲が曖昧な状態でシステムを導入してしまうと、失敗の元になります。

たとえば、「システムの機能だけ用意しておけば、ユーザーが自由に使ってくれるから問題ない」といった考え方があるとします。あるいは、「このシステムを誰が使うのかは、導入後に現場で決めてください」という状態です。このような進め方は、必ずといってよいほど運用上の混乱を招きます。

特に「計画系」の業務は、実績と違って伝票処理のように物理的な動きがありません。だからこそ、誰がその業務を実行するのか、そしてその人が持つべき「役割と責任」を、明確に定義しておく必要があります。

こうした運用基準やルールづくりは、社内で完結できることが望ましいですが、必要に応じて外部の協力も活用しながら整備していくことが、プロジェクト成功への大きな鍵になります。

SCMシステム「PlanNEL」によるSCM仕組み構築の始め方

さて、最後に少しだけ、私たちが提供しているSaaS型のSCMシステム「PlanNEL」についてご紹介させていただきます。

このPlanNELを導入すると、どのような業務イメージになるのかを、先ほどの共通フレームワークに沿って簡単にお見せしたいと思います。

業務イメージとしては、需要予測から販売計画、そして補充計画までの流れになります（図は需給計画の部分は省略しています）。

需要予測や販売計画によって、将来どのくらいの需要が見込まれるかを算出し、それに基づいて「どの程度補充すべきか」「どれくらい発注すべきか」をシステムが自動的に計算する流れです。

図の左側に記載されている通り、それぞれの業務に対応した担当者が、このような形で役割を担いながら、PlanNELを活用するイメージとなっています。

極端な言い方をすれば、「需要計画」さえ正確に作成できれば、「補充計画」はシステム側で自動的に生成されるようになります。

導入プロセスについても少しご説明します。

PlanNELはSaaS型ですので、従来のようなフルスクラッチの個別開発やカスタマイズは不要です。

その代わり、世界標準のSCMフレームワークとベストプラクティスをベースにした構造を採用しており、企業ごとの業務特性に合わせて、パラメータ設定やデータモデルの調整ができるようになっています。そのため、これまでのように、一から大規模なシステム開発プロジェクトを立ち上げる必要はなく利用ができます。

必要に応じてPOCを実施し、実際に自社業務に適合するかを検証したうえで、正式な導入プロジェクトへ進むというステップも取れます。

また、システム導入の際には「ロードマップの策定」や「アプローチ方法の合意」だけでなく、組織や業務プロセスの整備も必要になります。もちろん、こうした整備を導入前にしっかり準備しておくのも良い方法ですが、PlanNELであれば、実際にシステムを操作しながら、「自分たちの業務がどう変わるのか」を体感・検証しつつ進めていくことも可能です。つまり「システムを使いながら整える」というアプローチも取れるわけです。

PlanNELはSaaSとしてすでに各種昨日が準備されているため、ユーザー側で少し準備をしていただければ、すぐにでも活用いただける仕組みになっています。

また、システムを利用する前でも「在庫適正化診断」も可能です。

このサービスは、今お客様が保有している在庫が「多すぎるのか」「少なすぎるのか」あるいは「適正な水準にあるのか」を可視化するものです。いわゆる「適正在庫」とはどの程度の量なのか、それを定量的に算出することができます。

具体的には、お客様に在庫や販売の実績データをご提供いただき、そのデータをもとにPlanNELの在庫計画モジュールを活用して、適正在庫量をシミュレーションします。

その結果を、現在の在庫量と比較することで、過剰在庫や欠品リスクの可視化が可能になります。

たとえば、図に表示しているのは、実際のデータをもとに分析した例です。

ABC分析（売上貢献度の分類）とXYZ分析（需要の変動性）を掛け合わせて、「AランクかつXクラス」などの9つのマトリクスに分類しています。

Aランクは売上が高い重要アイテム、Cランクは売上貢献が低いアイテム、Xは需要が安定している（変動が少ない）、Zは需要が不安定で変動が大きいといった意味合いがあります。

たとえば「AX（売上高く、需要も安定）」のような“定番商品”に関しては、サービスレベル（欠品を防ぐための在庫水準）を高く設定し、欠品を起こさないよう多めに在庫を持つことが求められます。今回の診断では、安全サービスレベルを「97%」に設定しています。

この基準をもとに在庫を再計算した結果、AXカテゴリの製品については、現在より約1,400万円分の在庫削減が可能。一方でAZ（売上高いが需要が不安定）などについては、むしろもう少し多く持ったほうがよい、という結果が得られました。

このように、実際のデータを使って診断・可視化できるため、「今の在庫は最適なのか？」「どれだけ在庫を減らせる可能性があるのか？」「どのカテゴリに重点を置くべきか？」といった観点での業務改善に直結するインサイトを提供することが可能です。

PlanNEL導入の第一歩としてもご活用いただける、有用なサービスとなっております。もしご興味があれば、ぜひ一度お試しいただければと思います。

本日のセミナーは以上となりますが、もし追加でご質問やご興味がございましたら、いつでもお問い合わせください。

また、弊社では、SCMセミナーを月１回程度の頻度で開催しておりますので、ぜひまたご参加いただけたらと思います（セミナーの一覧はこちらから確認できます）。