Sales and Operations Planning（S＆OP）

Sales and Operations Planning（S＆OP）は、サプライチェーン以外の他の部門とのより深い連携を活用して、優れたサプライチェーンの実行を提供するための企業の実践です。主に営業、財務、生産などが含まれます。この実践は通常、営業予測から始まり、数量化された生産計画で終わる月次プロセスを中心に展開されます。この実践は、80年代にエンタープライズリソースプランニング（ERP）とMRPとともに登場し、予測の基礎となる数値を提供しました。

S＆OPの起源と動機

50年代と60年代の戦後経済は、さまざまな方法で簡単でした：オファリングを狭め、生産スループットを増やし、規模の経済によって価格を下げ、最後にマスメディアを通じて需要を増やす。しかし、20世紀末になると、サプライチェーンはこのモデルを超えて成長しました：より広範な製品ライン、より多くの地理的な場所、より多くのエシュロン。その結果、多くの非効率が現れ、サプライチェーンの概念が物流から独立した実践として浮上しました。この文脈で、S＆OPは80年代に造語され、企業は内部の「不整合」だけでかなりの財務的なオーバーヘッドを生み出すことに気付き始めました。S＆OP ¹ と情報のシロ ² は、1988年に形式化されました。

症状的なレベルでは、80年代に大企業は、サプライチェーンに一連の問題が広がっていることに気付きました：

• 同時に、企業はかなりの在庫超過と低いサービスレベルに直面する可能性がありました。
• オーバーサイズのエンジニアリングチームは、ほとんどのR＆Dイニシアチブを廃棄しましたが、重要な製品の納期遅れは解消されませんでした。
• マーケティングチームは、努力を間違った製品に向けることで、過剰生産または生産不足の問題を増幅させることになりました。

これらの問題に直面したS＆OPは、2つの異なる答えを提供しました。まず、早期のR＆Dからマーケティングまでの企業全体の調整は、最高経営責任者（CEO）を含むトップマネジメントの直接の責任となる必要がありました。この調整は、S＆OPによって概説された特定のプロセスに従って作成されます。第二に、プロセスは明示的かつ数量的にデータ駆動型になり、80年代後半の比較的新しいものであり、ERPの採用により電子的な在庫レベルと電子的な在庫移動が主流になったことが可能になりました。

S＆OPの5つのステップ

S＆OPプロセスは循環的であり、会社の選択によって毎年、四半期、および/または月次で一連のステップを経ます。会社のCEOは、プロセスを所有し、さまざまなステークホルダーが十分なリソースをS＆OPイニシアチブに割り当て、意図した企業全体の利益を提供するために十分なリソースを割り当てることを確認することが期待されています。プロセスは次のステップを経ることになります：

• 販売予測：販売チームからの数量的な洞察とともに、歴史的な販売データがまとめられ、通常は販売従業員から始まるボトムアップのプロセスに従っています。需要の予測値が作成されます。
• 需要計画：需要の予測の評価と検証。将来の需要に関する構造的な洞察の追加、および生の予測では反映されない戦略的リスクの特定（例：マーケティング活動のソースなどの予想される変動性の要因）。
• 供給計画：需要側および供給側の予測変動性を考慮した、需要を満たすために必要な予測される能力の評価と検証。必要な操作の優先順位付けとスケジューリング。
• プランの調整：需要計画と供給計画の調整、および会社の全体的な財務パフォーマンス（粗利、キャッシュフロー、長期的な顧客維持など）の評価。
• プランの最終化：プランの最終化と公開。会社内で広くアクセス可能にし、関係者がそれぞれの貢献を行うことができるようにします。

S＆OPプロセスには、組織のすべての機能間の焦点、調整、同期を促進するための一連のミーティングが含まれています。これらのミーティングは通常、「再計画」の機会であり、前回の計画を議論の出発点として活用し、修正が最も急務となる場所に取り組むように努めます。

ソフトウェアレベルでは、S＆OPは会社のトランザクションバックボーン（つまり、ERP（企業資源計画）、MRP（材料要件計画）、WMS（倉庫管理システム）、TMS（輸送管理システム））に依存して関連する過去のデータを取得しますが、通常は専用のソフトウェアコンポーネント（通常はAPS（高度な計画とスケジューリング））に分析のワークロードを委任します。 APSは、数値的な観点からS＆OPを明示的にサポートし（統計的な予測を計算するため）、ワークフローの観点からもサポートします（ユーザーが数値を修正および検証できるようにします）。

S＆OPのアンチパターン

「ベストインクラス」のビジネスがS＆OPの下で運営されているという複数のベンダーの主張にもかかわらず、ほとんどの実装は同様の欠陥に苦しんでいます。これらの欠陥は、S＆OPの本質に固有のものであり、次のようなものです：

• 関与する一部の当事者は、他の問題を導入せずには対処できない方法でS＆OPプロセスを歪める構造的なインセンティブを持っています。たとえば、「サンドバッグ」は、後で「期待を上回る」ために非常に保守的な目標を提出する広く行われている慣行を指します。これは通常、会社内での昇進/ボーナスの主な要因です。
• S＆OPに関与する当事者の数が非常に多いため、「委員会による設計」の状況になり、会社が生存に不可欠な決定を行うことができなくなることがしばしばあります。これらの決定は多くの参加者に強く反対される可能性があります。
• 最も好ましい状況でも、S＆OPプロセスは会社の経営チームにとって時間のかかるものです。S＆OPのオーバーヘッドが必要な悪であるかどうかは議論の余地がありますが、常に重いプロセスです。
• 予測は常にある程度間違っており、当事者間で常に論争の種となります。予測の精度を向上させようとする試みはほとんど常にソフトウェアの複雑さの増加をもたらしますが、ソフトウェアの信頼性が損なわれます。統計的な予測は、関与する多くの当事者（ソフトウェアベンダー自体を含むことがしばしばあります）にとって不透明な傾向があります。

S＆OPに対するほとんどの批判は、有効であろうとなかろうと、「真のスコットランド人ではない」という誤謬で片付けられています。哲学教授のブラッドリー・ダウデンは、次のように簡略化された誤謬を示しています。

Aさん: 「スコットランド人はオートミールに砂糖を入れません。」

Bさん: 「でも私の叔父アンガスはスコットランド人で、オートミールに砂糖を入れます。」

Aさん: 「しかし、真のスコットランド人はオートミールに砂糖を入れません。」

実際、S＆OPプロセスに苦しむ多くの企業では、合意が得られているのは、彼ら自身の不完全なS＆OPの味が問題であるということであり、代替の視点を考慮することはありません。つまり、S＆OPは会社を運営するために必要な要素であるかもしれませんが、予測可能なデメリットも伴います。

S＆OPの限界

ほとんどのアイデアと同様に、S＆OPもその時代の産物です：80年代です。この10年間で、サプライチェーンの予測最適化の実践は、当時は完全に想像できなかった方法で進化してきました。したがって、次のような主張ができます。

• S＆OPは「未来」の単純化された視点、つまり予想される将来の需要を反映しようとする古典的な時系列予測に重点を置いています。確率的な予測はS＆OPに存在しません。テールリスク、関連するサプライヤーまたは競合他社はモデルの一部ではありません。
• S＆OPは「人間を介した」視点に重点を置いているため、遅いです。多くの企業は月次のS＆OPを運用することができず、計画の四半期ごとの見直しにとどまっています。対照的に、現代のサプライチェーンは、機械による意思決定によって、無視できる遅延時間（数分以下）で提供されます。
• S＆OPは、需要側および供給側のデジタルマーケットプレイスを含む広範な相互接続されたアプリケーションの景気に合わせていません。企業は内部の調整だけでなく、市場レベルの調整（競争情報データの活用など）を求めています。
• S＆OPは、80年代に完全に理解されていなかった「規模の経済の逆効果」を軽視しています。サプライチェーンは、物理的なレベル（製品の増加、エシュロンの増加、輸送業者の増加など）だけでなく、ITレベル（トレーサビリティ、コンプライアンス、サイバーリスクなど）でも非常に複雑になった世界で、さらに悪化しています。

結論として、S＆OPは企業全体の調整の必要性やデータに基づく意思決定の重要性など、現代のサプライチェーンの中核に残る多くの課題を正しく認識しています。ただし、通常S＆OPと呼ばれるプロセスが提供するレシピは時代遅れです。

LokadのS＆OPに対する見解

ベストプラクティスは常に移り変わるものです。私たちの主な批判は、S＆OPが「付加価値を生み出さない」ことです：S＆OPプロセスに必要な人的リソースは「消費される」のではなく、「投資される」べきです。しかし、サプライチェーンは現在、ソフトウェアシステムを介して提供される数値的なレシピによって駆動されています。S＆OPは結果の改善に焦点を当てており、入力データが継続的に更新されるため、終わりのないプロセスです。対照的に、現代のアプローチは数値的なレシピ自体の改善に焦点を当てています（たとえば、機械学習などの高次元統計のさまざまなフレーバーを含む）- そして、それらの数値的なレシピをさらなる手動介入なしで運用します。

参考文献