副題: 事業計画の販売計画をもとにサプライチェーン上の製品供給の伝播(ブルウィップ)を可視化
英文タイトル: Python Demo for End-to-End Supply Chain Demand Planning
subtitle: "Visualizing the Propagation (Bullwhip Effect) of Product Supply in the Supply Chain based on Sales Plans in Business Planning"
【はじめに】
本記事は、以前に投稿したglobal weekly supply chain planの記事の続きです。
まず最初に、End 2 End Supply Chain のアニメーション表示をご紹介します。
以下の「図0のgifファイル」と「URLリンク先のhtmlファイル」のアニメーションは同じ内容ですが、以下URLをクリックすると事業拠点(node)が移動する様子をより分かりやすく表示しています。
yasushi-osugi.github.io/visualise-E2E-supply-chain/
2023年6月10日 追記: 需要サイド(outbound)と供給サイド(inbound)を接続した一気通貫のサプライチェーン(end to end supply chain)を可視化した「図0. end to end supply chain planning weekly accumed image 」を追加しました。中長期計画(5年間分)を前提に、最終消費地の月次販売計画を入力として、End2End supply chain全体に展開して、各事業拠点(node)の週次の需要計画と供給計画を生成しています。図0のアニメーションでは、流通市場への完成品供給が始まる前年の第40週辺りから部材サプライヤーの生産がスタートしています。その後、当年の年初(=53週)の辺りからマザープラントから流通市場への製品供給がスタートしている様子が分かります。※図0のアニメーション表示(gifファイルを生成)するpythonのソートコードは、下記githubにて公開しています。
Yasushi-Osugi/visualise-E2E-supply-chain: visualising End 2 End global weekly Supply Chain with plotly Sankey Diagram (github.com)
今回、作成したpythonデモの特長は、以下の２点です。
①サプライチェーンのEnd to End (最終消費～流通在庫～完成品生産～モジュール生産１次サプライヤー～基幹部品２次サプライヤー)を一気通貫する購買・販売・在庫(PSI)計画の連鎖を表現
そのために、サプライチェーン全体で共通の製品ロット単位、共通計画単位(common plan unit)を定義している。
➁計画処理スピードを重視したシンプルな計画モデルを定義
データの粒度を「週次バケットの共通ロット単位」とし、必要最低限の制約として、長期休暇(日本の５月の連休、お盆休み、中国の春節など)の非稼働カレンダーを考慮しながら、単純にリードタイム・オフセットする仕組みとした。
以上から、最終消費市場から部材サプライヤーまで、サプライチェーン上の複数拠点間のデータ整合性を取りながら、短時間で需給計画を生成できる機能を実装しました。
一方、今回は処理スピードを優先する観点から、利益や売上の最大化を考慮する最適化モジュール (線形計画や機械学習など) の実装は行っていません。なお、pythonコードの実装にあたっては、chatGTPとの会話から自動生成されたpythonコードを一部採用しています。
前回までの記事では、グローバル生産拠点・マザープラントから最終消費市場までの完成品流通（アウトバウンド）を対象にした需給計画を取り扱っていましたが、今回は、部材・基幹部品メーカーからマザープラントまで（インバウンド）を対象にした需給計画を取り扱えるように計画対象を拡張しました。
具体的には、マザープラントroot nodeにおいて、需要サイド（アウトバウンド）と供給サイド（インバウンド）のPSI 計画を接続する事で、サプライチェーンの端から端まで連携する需給計画機能を実現しています。
例えば、「図1. 供給サイド (インバウンド) サプライチェーンの在庫推移」では、最終市場の販売ロット情報が、流通経路を遡って、完成品の生産拠点を経由して、基幹部品の製造メーカーに配置されている様子が分かります。
図1の吹き出し表示のとおり、自動車の基幹部品のひとつであるワイヤーハーネスwireharness製造の第72週のロット番号26は、マザープラント(日本の完成品の生産出荷)を経由して、ドイツ ハンブルグ販売拠点のネット販売チャネルの2024年27週の販売ロットにリンクしている計画であることが分かります。
また、サプライチェーン上の各拠点nodeにおける在庫発注計画(PSI計画)の機能は、処理スピードを重視するために、できるかぎり簡単な仕組み (週次バケットの共通ロット単位データを単純にリードタイム・オフセットする仕組み) とすることで、サプライチェーン上の複数拠点間のデータ整合性を取りながら、短時間で需給計画を生成できるようにしました。
以下では、サプライチェーン上の在庫推移の様子を可視化して、3Dグラフとアニメーションで見ていきたいと思います。
【サプライチェーン需給計画の概要】
今回は、できるかぎりシンプルな計画立案方法を採用して、処理時間の短縮に配慮しています。
大前提として、中長期の事業計画を想定しており、計画対象期間は5年間(260週)分とする。
前処理として、サプライチェーン上の最終消費市場の月次の需要計画(事業計画における月次の販売計画)を入力として、ISO週の週次の需要計画に変換、生成しておきます。
以上の前提をもとに、
①global supply chainの需給計画を生成
②生産拠点マザープラントの生産平準化
③製品供給計画を生成
を処理して、在庫推移を可視化しました。
以下、サプライチェーン計画処理の概要を説明してから、出力される在庫推移のアニメーション(bullwhip animation)をご紹介します。
ご紹介したデモ版のpythonのソースコードは、下記URLのgithubにあります。※こちらのコードは整理されていないので読みづらいです。
Yasushi-Osugi/Yasushi-Osugi-bullwhip-image-on-supply-chain (github.com)
※アウトバウンド(需要サイド)とインバウンド(供給サイド)を接続した計画機能のpythonコードは下記URLのgithubを参照ください。
Yasushi-Osugi/global_weekly_Dm_Sp_visualise: global weekly Supply Chain connecting OUTBOUND and INBOUND (github.com)
【入力ファイル】
以下の２種類の入力データ、最終需要情報とサプライチェーン需給定義を用意します。
①サプライチェーンの需給関係(tree構造)
●流通サイドのoutboud tree定義 ※完成品から最終市場まで
●供給サイドのinbound tree定義 ※サプライヤーから完成生産まで(データ構造のみ対応)
➁月次の末端市場の最終需要計画を定義
【主要な処理】
①需要計画の生成 ※末端市場の需要から供給サイドに需要情報を展開
➁生産平準化処理 ※簡易的に生産能力の上限を設定して先行生産
➂供給計画の処理 ※マザープラントの確定出荷計画から末端の最終消費市場に向けて供給計画を展開
【出力】
上記を処理した後、在庫の推移を可視化
以下のリンクからサプライチェーンの在庫推移の様子supply chain bullwhip animationを可視化
供給計画の3Dイメージ「図2. 流通サイド (アウトバウンド) サプライチェーンの在庫推移」は、３次元の棒グラフ、
X軸: 時間 ISO Week
Y軸: 事業拠点 Location node
Z軸: ロットリストのロット数 Lot number on ID list
で供給計画を可視化しています。
以下のリンクからグラフ表示して、グラフを触ると回転するので、それぞれの軸から計画状態を確認することができます。
https://yasushi-osugi.github.io/demand-and-supply-planning/
【サプライチェーン在庫推移の可視化】
サプライチェーンの需給計画を検討していると、ブルウィップ効果(bullwhip effect)という言葉がでてくることがあります。サプライチェーン上の需要情報と製品供給の伝播、在庫推移の様子が波を打つように移動するイメージになることから、同様に波を打って増幅していくイメージの「鞭がしなる」bullwhipに例えてブルウィップ効果(bullwhip effect)と呼びます。
「図3. サプライチェーン拠点間(アウトバウンド)の在庫推移」のとおり、ブルウィップのアニメーションbullwhip animationは、サプライチェーン上の各事業拠点の在庫推移を週次の時系列でアニメーション表示しています。以下のリンクを参照。
https://yasushi-osugi.github.io/Yasushi-Osugi-bullwhip-image-on-supply-chain/
以上、簡単ですが、サプライチェーン上の在庫推移、ブルウィップの可視化について、ご紹介させていただきました。
【ご紹介したモデルの長所と短所】
今回は、流通サイドoutbound supply chainと部品素材の供給サイドinbound supply chainをマザープラントroot node で連結して、サプライチェーンの端から端までEnd to End supply chain ( 素材供給～完成品の生産～末端市場までのサプライチェーン全体) を一気通貫する需給計画を生成、可視化する機能を実装しました。
End to End supply chain 計画の長所は、以下のとおりです。
①部材メーカーの立場からは、最終消費市場での販売タイミングが分かるので、対象となる生産ロットの製品仕様を対象市場セグメント向けに合わせる事が、部材メーカー単独の予測ではなく、サプライチェーン全体の共通認識としてできるようになります。
②末端の販売チャネルの立場からは、自身に割当られた商品が、いつ何処で生産され、輸送され、在庫されて来るのかが分かるので、むやみに在庫を積み増して、結果的に不良在庫や廃棄ロスを発生させずに済むようになります。それぞれの販売チャネルは、自身の販売促進に専念することができます。
③グローバル営業本部とマザープラントの立場からは、事業計画の企画販売数を週次で補足することで、特定の地域市場で競合メーカーが販促を仕掛けてくるケースや、基幹部品サプライヤーの供給量が変動するケースなど、環境変化への対応、意思決定をサプライチェーン全体を見渡しながら、優先順位を明確にした対処ができるようになります。
本モデルの短所とその対策は以下のとおりです。
① 最適化モジュールの必要性: 処理スピードを重視するため、利益や売上を最大化するための最適化モジュール（線形計画や機械学習など）の実装は行われていません。
したがって、収益最大化や最適な意思決定を考慮する場合には、追加のモジュールを組み込む必要があります。
➁ データ粒度の制約: 「週次バケットの共通ロット単位」をデータ粒度としていますが、これは必ずしも現実のサプライチェーンのすべての要素に対して最適な粒度ではありません。
ニーズに応じて、より詳細な粒度が必要な場合があります。
➂ サプライチェーン内の全拠点へ適用時の制約: サプライチェーン上の拠点数が増えると、処理時間や計算量が急速に増加します。
また、計画処理のスピードを重視したモデルになっているのですが、供給サイドinboundの可視化、3Dグラフ表示処理では共通ロット数が増えると表示時間が極端に長くなってしまいました。
大規模で複雑なサプライチェーンに対しては、モデルの拡張方法や内部処理の最適化、可視化の方法などで工夫が必要になります。
④ サプライチェーンモデルの表現力: 本モデルでは非常にシンプルな計画モデルを採用していますが、サプライチェーン内のさまざまな要素や制約をglobal weekly PSI planのモデルとして、より現実的なシナリオや特定のビジネスニーズに対応するためには、どのようにモデル化していけば良いか、モデル構築のノウハウの蓄積が必要となります。
ご紹介したモデルは、週次のリードタイムのパラメーター設定が輸送期間と在庫滞留期間を表現するというシンプルなモデルですが、このデータ構造をベースに、出荷指示のコントロールにPUSH方式とPULL方式の仕組みを組合せて実装することで、サプライチェーン計画モデルのシミュレーション機能を実態に合わせて拡張していくことができるのではないかと考えています。
それから、需要情報の取り扱いについて、今回のデモにおいては「事業計画の販売計画」という事業責任者の意思入れがされた数字を前提としていますが、実際には、需要は変化し続け、需要予測の精度に依存する仕組みである事から、実績との誤差を吸収する仕組みを設置する必要があります。
例えば、輸送手段が船便の場合、輸送時間が10週間を超えるなど、計画リードタイムも長くなるので、供給量のアクセル・ブレーキにタイムラグが発生します。予測の誤差も大きくなります。
対処方法としては、
1. 誤差を吸収するバッファ在庫の配置を検討する事
2. 輸送手段をエア便に変更する事
3. マザープラントの供給量の増減で対応する事
などが実態ですが、このような変化対応の仕組みを計画モデル上で同様に表現することが課題になります。
【今後の取り組みについて】
今後の取り組みとしては、サプライチェーン全体を見通せる供給計画と在庫推移の可視化、および対話型の計画シミュレーションの仕組み、最適化モジュールの組み込みなどを検討していきたいと思います。
ところで、今回ご紹介したpythonコードの一部は、chatGPTに要求仕様を提示して生成されたコードを採用しています。例えば、pythonコード中の内包表現やtree構造のポインター操作などは、chatGPTが生成したコードを参考にしています。
おそらく、私の経験からは、私自身の開発生産性は10倍～100倍上がった感覚で、構想レベルでの検討に割く時間がふえました。
またchatGPTは、構想レベルの検討にも的確な回答を生成してくれるので、今回の取り組みの方向性を検討する上でも非常に参考になります。
2023年5月
大杉 泰司 with chatGPT
