「ワンクリック」より速い: なぜプログラム可能なサプライチェーンがスピードで勝つのか
サプライチェーンでは、スピードについて多く語られます。補充の速度、対応の速度、そして何か問題が起きたときの回復の速度。しかし、これらの意思決定をサポートするシステムに目を向けると、スピードの議論はすぐに一つの指標に収束します――ソフトウェア契約締結後、「稼働」するまでに何週間かかるかという点です。
大手のサプライチェーンソフトウェアベンダーのほとんどは、その質問に対して非常に明確な答えを持っています。彼らは、事前に構成されたコンテンツ、標準データモデル、そして「業界のベストプラクティス」によって、迅速な価値提供（time‑to‑value）を実現すると約束しています。統合型ビジネスプランニングスイートや先進的なプランニングシステムのマーケティングを見ると、その物語は非常に一貫しています。すなわち、リファレンスモデルから始め、いくつかのテンプレートを適用すれば、「数週間」または「最短12週間」で生産稼動できる――時には明言して「Excelから数週間で先進プランニングへ」とも称されます。
最近、私自身の書籍 Introduction to Supply Chain において、この物語から一歩引いた視点を試みました。その中で、サプライチェーンを、日々不確実性の中で利益をもたらす意思決定を行うビジネスとして位置づけています。この視点を真剣に受け止めるならば、「どれだけ早くソフトウェアを展開できるか？」という問いは、「どれだけ早く高品質で自動化された意思決定を生産稼動させ、かつビジネスの変化に合わせてそれを維持できるか？」という問いに変わります。これは全く別の問題です。
そこから導かれる結論は、主流とは逆のものです。本格的なサプライチェーンの取り組みにおいて、プログラム可能なアプローチは従来のパッケージソフトウェアよりも強力なだけでなく、実際に意味のある成果を生産に投入するのがより早いのです。
その理由を説明しましょう。
事前構成済みサプライチェーンソフトウェアの安心感のある約束
伝統的なエンタープライズプランニングベンダーは、安心感のあるストーリーを提供します。
彼らはサプライチェーン向けの標準的なデータモデル、すなわち拠点、製品、階層、部品表、カレンダー、リードタイム、制約などからスタートします。このモデルの上に、事前構成済みのプロセス（「ベストプラクティス」）、サンプルデータセット、テンプレートのダッシュボード、アラート、標準アルゴリズム、そして設定ガイドが組み込まれています。これらすべての資料は、実装を迅速化しプロジェクトのリスクを低減するために明示的に設計されています。
この論理は完全に一貫しています。もしすべての顧客のデータとプロセスが共通のテンプレートの控えめなバリエーションとして記述可能であれば、大部分の作業は再利用可能なはずです。実装プロジェクトは、ERPフィールドをプランニングモデルにマッピングし、関連機能をオンにし、パラメーターを調整し、画面の使用法を教えるという単純な作業に過ぎなくなります。
その世界では、カスタマイゼーションは必要悪とされています。「特別」なケースでは受け入れられますが、同時にそれが遅延、予算超過、長期的な複雑さの主な原因として認識されています。したがって、「カスタマイズではなくコンフィギュレーション」を推進し、さらに最近では、ローコードおよびノーコードツールを導入して、ソフトウェアがすでに実行できる範囲内に留まるように努めています。
これらの前提の下では、パッケージソフトウェアの方が迅速に展開できるという考えは完全に合理的です。
しかし、実際のサプライチェーンはめったにその前提に合致しません。
プロジェクトが本当に遅れる部分：画面ではなくセマンティクス
大規模なサプライチェーンシステムの展開で実際に時間が費やされるのは、ソフトウェアのインストールやユーザートレーニングではなく、データの意味を理解することにあります。
多くの大企業は1つ以上のERPを保有し、さらにCRM、WMS、TMS、PIM、e‑コマースなどの他のシステムが散在しています。これらを合わせると、何千ものテーブルが存在します。形式的には、これらのエンティティには文書化された意味があるはずですが、実際には、それらの真のセマンティクスは、何年にもわたる回避策、ローカルな慣習、妥協、そして部分的なクリーンアップの結果として形成されています。システムの真の動作は、元のベンダーが意図した使い方ではなく、人々が実際にどう使用するかによって定義されるのです。
プランニングスイートが導入されると、それは独自のデータモデルと期待をもたらします。同じERPのベンダーから提供された場合であっても、セマンティクスは完全には一致しません。「location type」や「safety stock」といったフィールドは、構成、日常業務、レポート作成、さらにはプランニングエンジン内で、同じ意味を持つとは限らないのです。
このすべてを調整する必要が生じます。
その調整を担うのは、通常、IT、コンサルタント、そしてビジネスステークホルダーからなる混成チームです。彼らは、どのテーブルが権威あるもので、どのフィールドが信頼に足るか、例外をどのように扱うか、そして企業の乱雑な現実をプランニングソフトウェアが要求する整然とした構造にどのようにマッピングするかを決定しなければなりません。彼らは抽出および変換のジョブを作成し、カスタムフラグや属性を追加し、標準モデルでは表現しきれない制約をコード化するための慣例を発明します。
これが、いわゆる「ワンクリック」展開が、広範な統合作業へと変貌する転換点です。ソフトウェア自体は初日から稼働しているかもしれませんが、真剣な最適化エンジンが要求する正確で信頼性のある日次データ、つまり必要なデータが実際に安定するまでには、数ヶ月、あるいは数年かかるのです。
これは実装の失敗ではなく、もっと深い事実の表れです。セマンティクスはローカルなものであり、特定の企業のサプライチェーンを普遍的で即使用可能な形で表現することは不可能なのです。
サプライチェーンはコンフィギュレーションではなくソフトウェアとして
セマンティクスがローカルであり、ビジネスの変化とともに進化し続けるという前提を受け入れるならば、「コンフィギュレーション」と「カスタマイゼーション」という通常の区別は誤解を招くものとなります。
根本的には、大胆なサプライチェーンの取り組みは常にソフトウェアの実装です。それは、利用可能なデータと制約を踏まえて、企業が購買、生産、在庫、価格設定、割り当てなどについてどのように意思決定を行いたいかを、正確かつ実行可能な形で定義する行為です。
従来のパッケージモデルでは、このソフトウェアはコンフィギュレーションテーブル、パラメーター、ワークフローダイアグラム、カスタムコネクタ、そして場合によっては汎用言語で書かれた「ユーザーエグジット」から構成されます。ほとんどのロジックがコンフィギュレーションで表現可能で、周辺部分だけがコードを必要とすることが期待されます。
私の経験では、特に複雑な環境においては、逆の現象が起こります。最も重要で差別化を図るロジックは、不安定な方法で実装される結果となるのです。すなわち、フィールドの過負荷、公式システムの横にExcelシートやPythonノートブックを重ね合わせること、さらにプランナーがどこにも明示されていない特定の方法でダッシュボードを解釈するよう指導することによってです。
その結果、「システム」は部分的にはソフトウェアに、そして部分的には人々の頭の中に存在することになります。
Lokadでは、10年以上前に、問題のソフトウェア的性質を受け入れることに決め、対抗するのではなくそれを前向きに活用する道を選びました。私たちは、プロのソフトウェアエンジニアではなくサプライチェーンの実務者を対象とした独自のドメイン固有言語「Envision」を構築しました。その考えはシンプルです。すべてのデータ変換、すべての予測、すべての制約、そしてすべての意思決定を、読み取り、バージョン管理、テスト、そして制御された方法で修正可能なスクリプトとして表現するのです。
外部から見ると、これはプログラミング環境のように見えます。内部的には、複雑な現実を市販モデルに無理やり押し込むのではなく、実際の現実をそのまま記述するための柔軟な言語を私たち自身に与えるという、セマンティックな問題に対する私たちの答えなのです。
これにより、速度の問題に再び目を向けることとなります。
サプライチェーンにおいて「速い」とはどういう意味か？
もし速度を「ソフトウェアベンダーがチェックリストに従い稼働を宣言できるまでの時間」と定義するならば、事前構成済みスイートはしばしばより速く見えるでしょう。プロジェクト計画はそのマイルストーンに最適化され、標準モデルは素早くデータが入力されるよう設計されています。また、トレーニング資料とベストプラクティスもその特定の目標に沿って整えられています。
しかし、速度を「実際の資金を託せるライブの自動化された意思決定フローが稼働するまでの時間」と定義するならば、状況は大きく変わります。
プログラム可能なアプローチでは、プロジェクトの進行は通常、次のようなシーケンスとなります：
まず、既存システムから信頼できる日次抽出を設定します。それらを新しい標準モデルに無理やり当てはめようとはしません。これは依然として大変な作業ですが、主にパイプラインの整備、つまり、ありのままの生データ―その醜さも含めて―を取り出すことに尽きます。
次に、プログラム可能な環境内で、ビジネスロジックを段階的に表現します。具体的には、データの整備と照合、制約と優先順位の表現、不確実性のモデリング、そして最終的に注文数量、生産計画、割り当てといった具体的な意思決定を計算します。このロジックが専用言語で記述されているため、変更のサイクルは短く、サプライチェーンの専門家はエッジケースや新たな要件が現れるたびに、日単位または週単位でそれを洗練させることが可能です。
最後に、これらの意思決定をデュアルランに投入します。つまり、スクリプトが提案する内容と実際にプランナーが行うことを比較し、財務的な影響を測定し、必要に応じて調整を行います。信頼性が十分に高まったら、厳選されたポートフォリオの領域についてはスクリプトに制御を委ねます。
重要な点は、このシーケンスが反復的であるということです。初版のロジックが完璧であることも、環境がそのまま固定されることも期待していません。むしろ、品揃え、ネットワーク、サービスの約束、競争環境が進化するにつれて、意思決定ルールはほぼ毎年または二年ごとに大幅に書き直される必要があると想定しています。
そのような状況下での「速さ」を決定する主要な要因は、最初の稼働日ではなく、平均変更時間、すなわち、ビジネスが運用方法を変更すると決定したときに、システムの調整にかかる時間なのです。
たとえ、ある価格政策をモノリシックなプランニングスイートでエンコードするのに6か月かかったとしても、元の実装が3年前に予定通り完了していたという事実は意味を持たなくなります。
システムの全寿命期間において、なぜプログラム可能性がより速くなるのか
外部から見ると、プログラム可能性は重荷のように映ります。既存の画面を設定するよりも、コードを書く方が遅いに決まっている、と思われるかもしれません。
単純な場合にはその通りであることもあります。もしサプライチェーンが比較的小規模で安定し、ベンダーのリファレンスモデルに近いものであれば、事前構成済みのソリューションは確かに受け入れ可能な定常状態に迅速に到達するかもしれません。多くの企業はプランニングツールを厳格に活用しておらず、むしろ、より良いUIといくつかのアラートを備えた構造化スプレッドシートとして利用しているのです。その文脈では、パッケージ型アプローチは狭義には適切であり、速いと言えるでしょう。
状況は、次のような環境に移行した途端、劇的に変化します：
-
大規模で多様（複数のERP、異なる事業部、さまざまな種類の製品やチャネル）、
-
変動が激しい（品揃え、リードタイム、サービスの約束が頻繁に変化）、
-
そして野心的（単なる意思決定支援ではなく、高度な自動化を目指す）。
そのような場合、事前構成済みのソリューションは3つの構造的課題に直面します。
第一に、セマンティックギャップが大きすぎるという点です。例外やローカルな慣習が多ければ多いほど、標準モデルはそれらに対応するために歪められる必要があります。その歪みの一つ一つが、構成上のトリック、カスタム拡張、または補助的プロセスへと変わっていき、時間の経過とともにシステムは理解しにくく、なおさらクリーンアップが難しい特殊ケースの層を積み重ねてしまいます。
第二に、変更のコストが外部によって管理されている点です。大規模なプランニングスイートのロジックを変更する場合、通常、内部IT、外部コンサルタント、場合によってはベンダー自体など、複数の層が関与します。リリースサイクル、テストプロトコル、安全性を重視したガバナンスプロセスが存在するため、敏捷性ではなく安全性が優先され、合理的な中程度の変更でさえも数ヶ月を要するのです。
第三に、ロジック自体が急速に陳腐化する点です。3年前には理にかなっていたサプライチェーンのルールも、今日では最適とは言えません。そのルールを再検討するコストが高い場合、組織はその取り組みを先延ばしにする傾向があります。結果として、エッジ部分をスプレッドシートやオーバーライド、そして緊急対応で補完することになります。
対照的に、プログラム可能なアプローチは、そのコストの大部分を前払いします。つまり、基本的にはソフトウェアを書いていることを受け入れなければならないのです。しかし、一度、サプライチェーンの専門家が利用可能で、かつビジネスの現実を十分に表現できる専用環境が整えば、変更にかかる経済性は一変します。
新たな制約の追加、新規データソースの統合、またはプロモーションの取り扱い方法の改訂は、新たな実装フェーズの交渉ではなく、スクリプトの編集の問題となります。意思決定ロジックが明示的であるため、バージョン管理、テスト、ロールバックが可能です。また、設定テーブルや補助ファイルに散在するのではなく一元管理されるので、全体として論理的に考察できます。
これは主流ソフトウェアの否定ではない
これをすべてのパッケージ化されたサプライチェーンソフトウェアに対する批判と解釈するのは誤りです。これらのシステムは多くの問題を確実に解決します。堅牢なトランザクション処理を提供し、広範なエコシステムと統合し、ユーザーインターフェース、セキュリティモデル、監査可能性、そしてゼロから再現するには高コストなコンプライアンス機能を備えています。
また、これは各企業が汎用プログラミング言語を用いてすべてを社内で構築すべきだという呼びかけでもありません。その道は無秩序にカスタムスクリプトが増殖し、独自の脆弱性を招く結果となります。
私が提唱しているのは、異なるアプローチです――それは、意思決定ロジックのためのプログラム可能なコアを採用し、その他の部分には最高のパッケージシステムを利用するというものです。
言い換えれば、ERP、WMS、TMSは、それぞれ得意な分野、つまり実際に起こった事象の記録、単純なビジネスルールの実施、ワークフローの調整に専念させ、標準機能が真にあなたのニーズに合致する場合は、専門のプランニングスイートを利用すべきです。しかし、これらのパッケージツールに、最も重要で、最もダイナミックで、差別化を図る意思決定ロジックが存在すると期待してはなりません。
そのためには、初めからあなたのサプライチェーンがユニークであり、変化するものであり、あらゆる本格的な取り組みが最終的にはどのテンプレートも予期しなかったセマンティックな詳細に直面するという現実を受け入れる仕組みが必要なのです。
ドメイン固有言語である Envision のようなものは、一つの解答となり得る。それは、供給網の専門家が仲介者の層を経ずに自らのロジックを直接表現・管理する能力を持つために、Lokad で何年にもわたって構築・洗練されたものです。
他のベンダーも様々な形で同様の考え方を追求してきました。重要なのは「DSL」という呼称ではなく、その根底にある原則―意思決定ロジックはファーストクラスであり、プログラム可能であり、ビジネスの経済を理解する人々に所有されるべきである―ということです。
スピードの再考
もしスピードを「堅牢で自動化された意思決定をどれだけ早く運用に乗せ、必要なときにはどれだけ早く改訂できるか」と再定義するなら、その結論は避けられません。
短期的には、あらかじめ構成されたスイートは、初期に目に見える作業を最小限に抑え、儀式的な運用開始を最適化するため、より速く見えることがあります。しかし中長期的には、その硬直性と変更コストが、ビジネス環境が変化する――すなわちスピードが最も必要とされる時――に、かえって遅延を招きます。
プログラム的アプローチは初期投入の作業が多いですが、現実が初期仮定から逸脱するたび、つまり常に、その効果を発揮します。
問題は、供給網のためにソフトウェアを書くかどうかではありません。事業が十分に大きく複雑であれば、既に構成、スプレッドシート、ローカルスクリプトおよび手動の慣行を通じてソフトウェアを利用しているのです。本当に問うべきは、そのソフトウェアが明示的で一貫性があり、かつ自分たちの管理下に置かれているかどうかです。
私の答えは明確です。意味のあるスピードを追求するのであれば、供給網はプログラム可能でなければなりません。
