支払い条件はサプライチェーン内にある
支払い条件は通常、管理上の細部として扱われる。調達部門が交渉し、買掛金部門が記録し、財務部門が現金の影響を監視する。計画部門は数種の概要指標を受け取り、そのまま業務を続けることが期待される。この労働分担は書面上は整然としているが、実際には費用がかかる。なぜなら、運用上の意思決定から、その意思決定がそもそも存在すべきかどうかを決定する変数の一つが除外されてしまうからである。
より詳細な解説を求める読者は、特に第4章4.4節および第8章8.6節を含むサプライチェーン入門でその内容を見つけることができる。購買注文は後で商品を受け取るための約束だけではなく、期日付きの現金債務の連なりでもある。その連なりを変えれば、注文自体の経済性も変わる。同じ単価の二つの提案であっても、支払いカレンダーが異なればもはや同じ提案ではない。
例えば、同じ名目価格で同一商品を販売する二人の供給業者を考えてみよう。一方は生産前にデポジットを、出荷時に残額を要求し、もう一方は受領後かなり後に支払いを許可する。価格表上では互換可能に見えるが、実際はそうではない。後者の供給業者は、現金が引き落とされる前に買い手が在庫の重要な部分を販売することを許すかもしれない。動きの速い商品では、その違いにより実際の現金露出がほとんどなくなる可能性がある。一方、季節商品や不確実な商品では、許容できる賭けと危険な賭けの差となる。
支払い条件は、単一の注文にかかる資金調達コスト以上の影響を及ぼすため、サプライチェーンの内部に組み込まれるべきである。これらは資本の競合用途の順位を変える。厳しい条件で購入された低回転品は、数ヶ月にわたり資金を固定化し、他の場所での迅速な回転を十回分ほど圧迫するかもしれない。やや高価な供給業者で好条件を提示する場合、企業は他の流れの資金調達が継続できるため、経済的に優れた選択となり得る。関連する損害は、単に貸借対照表の比率に現れるだけでなく、後に小規模な購入、品揃えの狭小化、補充の遅延、そして現金がより多く稼げたであろう場所での在庫切れとして表れる。
この点が理解されると、業界で広くみられる習慣が脆弱に思えてくる。可視化は役立つが、それ自体が目的ではない。実際の意思決定の順序を変えずに支払い条件やキャッシュフローの影響を表示するダッシュボードは、核心的な問題に手を付けていない。真剣な計画システムは、支払いタイミングが行動の優先順位に影響を与えることを許容しなければならない。そうでなければ、データは記述的なままで、限られた資源の配分は最も厳しい制約の一つに気づかないままとなる。
なぜソフトウェアはこれを未だに誤るのか
大手ベンダーの公開資料を見ると、支払い条件を主に記録として扱うソフトウェアのカテゴリーが依然として存在する。Oracleの調達ドキュメントはその役割を明確にしており、支払い条件は購買注文または供給業者のサイトから請求書に引き継がれ、そこで上書き可能となる。これは有用な事務処理の仕組みであり、義務が正しく保存・回覧・決済されることを保証する。しかし、これではどの購買注文行がそもそも存在すべきかを決定する論理に支払い条件が組み込まれているとは言えない。
第二のカテゴリーは、代理を通して金融を扱う。SAPのIBPドキュメントは、在庫保管コストに資本コストを含めることを前提とし、最適化装置をコスト率と総コストの実現可能性に集中させる。現金が無料であると仮定するよりは良いが、それでもなお不器用な手法である。一般的な保管コスト率では、デポジット、マイルストーン支払い、委託契約、早期支払い割引、またはサイト、カテゴリ、契約ごとに異なる供給業者固有のカレンダーを忠実に表現することはできない。選択の瞬間に重要な詳細は平均化されてしまう。
さらに上位では、市場は財務と供給を同じ議論に組み込む統合計画を販売している。OracleはS&OPを、収益、利益率、コスト目標を供給計画に変換するものと説明している。o9は、運用計画の横に運転資本の制約とキャッシュフロー予測を配置する。e2openは、実行と財務を整合させ、運転資本の改善を謳う連携型計画を提供している。Blue YonderのIBPページでは、貨幣化された供給計画、キャッシュフロー、運転資本、そしてエグゼクティブ向けダッシュボードについて語られている。これは有用な取り組みであり、経営陣が運用上の選択の財務的影響を理解するのに役立つ。しかし、公開資料は実際の争点からは一段階上の議論に留まっており、支払いカレンダーが個々の補充、調達、または展開の決定の評価を変える様子よりも、合意形成、シナリオ、ギャップ、ガバナンスについて多く語っている。
より現場に近い取り組みもある。Kinaxisは、支払い条件、ペナルティ条項、ボーナス条項を含むプロジェクト指向の計画の公開資料を提供している。Blue Yonderの小売計画ページは、財務目標を購買予算、配分、補充のワークフローに組み込んでいる。これらは意義ある前進である。それでも重点は、契約の視点、予算枠、シナリオの柔軟性、および下流との同期に置かれている。私が検討した公開資料では、決定的な疑問、すなわち、二つの運用行動が次のユーロを巡って競合する際、支払い日がどのようにスコアリングに組み込まれているのかという点は未だに解明されていない。
支払いタイミングが明確に最重要となると、それはしばしば個別の買掛金またはサプライチェーンファイナンスプラットフォームへ移行する。SAP Tauliaは、ダイナミックディスカウンティング、サプライチェーンファイナンス、早期支払い、流動性、そして供給業者の資金調達に焦点を当てる。C2FOは、供給業者のファイナンス、支払い条件の最適化、資金源、運転資本プログラムに焦点を当てる。これらの存在は、支払いタイミングのビジネス上の重要性を証明するものである。また、実務上依然として見られる分断を明らかにしている。あるシステムは支払い条件を保存し、別のシステムは商品の流れを最適化し、さらに別のシステムが現金の流れを最適化する。これら三者の連携は、ビジネスの経済性が要求するほど強固ではない。
台帳ソフトウェアは、フォーム、ワークフロー、監査トレイルに優れている。エグゼクティブ向け計画ソフトウェアは、計画を財務的な視点に統合するのが得意だ。しかし、意思決定エンジンはより困難な任務を担う。不確実性の中で何千、何百万という候補行動を比較しなければならず、現金、能力、スペースといった共有の制約が各コミットメントごとに引き締められたり緩和されたりする。公開されているベンダー資料は、ランキングそのものを所有するシステムを出荷するよりも、別の画面やワークフロー、ダッシュボードを売る方がいかに容易であるかを示している。
支払い条件を考慮したシステムが行うべきこと
この見解は、現行のソフトウェアパンフレット群よりも以前から存在する。オペレーションとファイナンスの研究は、支払いの遅延、貿易信用、資金調達の選択、在庫方針を一体の問題として何年も検討してきた。EPFLのサプライチェーンファイナンス研究グループは、変動する支払い条件と運転資本管理を明示的に研究しており、その成果は、支払い遅延と運転資本の制約を、注文上限の決定と共にモデル化している。他のオペレーションズリサーチの論文も、卸売価格や発注数量と並んで、支払い期間を意思決定変数として扱っている。概念上の基盤は長い間整えられてきた。
支払い条件を真剣に考慮する計画エンジンは、各候補行動を一つのパッケージとして評価する。このパッケージには、期待される商業的リターン、現金流出の日時と金額、現金回収の見込み時期、そしてその現金が利用できない間に事業全体に課される機会費用が含まれる。流動性への圧力が軽微であっても、これにより選好が変わる。流動性の圧力が強い場合には、実現可能性そのものが変化する。単独では利益を生む行動であっても、より良い行動への資金供給を阻害するため、順位を失う可能性がある。
このことは非常に早く具体化する。単位あたりわずかに高い料金を課す供給業者が、支払い条件が前払い30%ではなくネット90であるために注文に値する場合がある。大規模な季節購入は、その現金負担が一連のより迅速かつ安全な回転を妨げるまで魅力的に見える。早期支払い割引は、同じ現金が他でより多く稼げるため、ある製品群では受け入れられ、別の製品群では却下されるに値する。これらの判断は、計画が承認された後のダッシュボードで決定できるものではない。それらは、計画が行ごとに形成され、資本の他のすべての候補と競合する際に下されるべきである。
有用な成果物とは、現金の確保や解放に応じて再編成される、優先順位付けされた意思決定のキューである。もし信用枠が引き締まれば、そのキューは即座に変わるべきだ。もし供給業者があるカテゴリでより良い条件を提示すれば、該当するSKUは上位に移動する。もし低回転品で支払いスケジュールが悪化すれば、その購入は順位が下がるか、消滅すべきである。こここそが支払い条件がその価値を発揮する場所である。支払い条件は、購買注文、転送、生産スロット、値下げにわたる現金の細分化された配分を変える必要がある。それ以下では、単なる会計上の可視性が運用インテリジェンスとして装われているに過ぎない。
この点に関してソフトウェアを購入する者は、演出の余地を与えないデモンストレーションを要求すべきである。供給業者に、異なるデポジットと支払い期限を持つ二つの同等の供給業者を提示し、利用可能な現金を制約した状況を示すよう求めよ。最初にどの行が削除されるのか、そしてその理由は何かを問え。支払い日が目的関数にどのように組み込まれているかを尋ね、条件変更前後の順位付けされた行動リストを見せるよう要求せよ。もし回答が設定画面、運転資本のKPI、またはエグゼクティブ向けダッシュボードであるならば、問題の核心は依然としてシステムの外にある。
支払い条件がサプライチェーン内に属する理由は、リードタイム、最小注文量、保管制限がそこに属する理由と同じである。それらは、どの物理的流れを追求すべきか、追求すべきでないかを決定する。もしフォーム上のフィールドや月次レビューのただの数字として扱われれば、ビジネスは依然としてその影響を受けるだろうが、その影響に気づくのは遅すぎるだけである.
