サプライチェーンには設定可能な製品ではなく、プログラム可能なシステムが必要
最近、サプライチェーン入門という無料のオンライン書籍を公開しました。本書では、サプライチェーンの意思決定は「設定可能な」ソフトウェア製品ではなく、プログラム的なシステムによって行われるべきだと主張しています。本書は意図的に幅広い内容となっているため、今回は特定の一つの考えに焦点を当てたいと思います。それは、なぜロカッドが徹底したプログラム指向の姿勢を採用しているのか、そしてそれがなぜ一般的なサプライチェーンソフトウェアの見解と対立するのかという点です。
特定のベンダーについては議論しません。私が興味を持っているのは、その根底にある哲学、つまりサプライチェーンにとってどのようなソフトウェアが本当に適切なのかという点です。
一般的なソフトウェアが具体的なサプライチェーンで苦戦する理由
今日、サプライチェーン向けに販売されるほとんどのソフトウェアは、似たような構成を踏襲しています。
まず、トランザクションのバックボーン、すなわち注文、受領、在庫の移動、請求書、出荷などを記録する仕組みから始めます。この層は比較的標準化されています。顧客、購買注文、SKU、ロケーションといったおなじみのエンティティを扱います。多くの業界で汎用的かつ再利用可能であることが期待されており、実際にその通りになっています。
このバックボーンの上に、「プランニング」または「最適化」モジュールを追加します。これらのモジュールは、過去および現在のデータをより良い意思決定、すなわち購買注文、転送、生産計画、割り当て、価格などに変換することを約束します。ベンダーは通常、これらの機能を設定可能なアプリケーションとして提供します。ロジックを自ら記述するのではなく、設定によって定義します。ルールを定め、パラメーターを設定し、モデルを調整し、「ベストプラクティス」のプロセスを採用するのです。
一見すると、このアプローチは全く合理的に見えます。実際、どこでも似たような問題が見受けられます。例えば、どれだけ購入すべきか、どこに配置すべきか、いつ移動させるべきか、何を約束すべきか、何を割引すべきかといった問題です。確かに、汎用プラットフォームならば、それらの問題に対して再利用可能な解決策を提供できるでしょう。
しかし、実際のサプライチェーンを詳細に見ると、頑固な障害となるもの、すなわち固有の特性が存在することがわかります。
ケーブルのディストリビューターは、1万メートルのケーブルが「一つの数字」ではないことに気付くのです。その長さがリール間でどのように分割されるか、顧客が実際に注文する長さ、受け入れ可能な切断損失、そしてマージンを損なわずに約束できる切断がどれかによって異なるからです。
航空宇宙企業は、「在庫の1個」が、独自の整備履歴や認証の制約、複雑な代替規則を持つシリアル化された部品を隠している可能性があることに気付くのです。
ファッション小売業者は、需要が単なる「SKU」ではなく、品揃え全体に対してあることを学びます。特定のサイズと色の組み合わせが共に存在しなければ、在庫がどれだけあってもそのカテゴリー全体のパフォーマンスが低下してしまうのです。
こうした状況を汎用的な意思決定エンジンに詰め込もうとすると、単なる例外事例として扱われるのではなく、事業の核となる要素として現れます。各企業は、テンプレートに収まらない独自の「ケーブル」、すなわち全体の収益性を左右する制約や経済性を持っています。
実際の結果はよくある光景です。中央に設定可能なプランニングモジュールがあり、周辺にはスプレッドシートが配置され、人間のプランナーが常にその隙間を補っています。
なぜ設定だけでは不十分なのか
設定可能なプランニングソフトウェアに秘められた夢は、複雑さを選択肢、すなわちより多くのパラメーター、より多くのトグル、より多くのルールタイプ、より多くのテンプレートによって制御できるというものです。プログラミングをしなくても、設定を通じてソフトウェアに何をすべきかを「教える」ことができるはずなのです。
残念ながら、設定には厳しい限界があります。
設定は、問題の形が既に明らかである場合に機能します。もし全ての企業が同じ制約や経済性の構造、需要の挙動や在庫の反応に関する同じ概念モデルを共有していれば、あらかじめ定義された一連のルールに対して値を選ぶだけで十分でしょう。
しかし、実際のサプライチェーンは、適切なパラメーターを待っている固定されたパズルではありません。競合、規制、物流ネットワーク、そして絶えず変化する顧客の習慣によって形作られる動的なターゲットなのです。さらに、最も大きな影響を与える制約は、しばしば誰の標準モデルにも適合しないものです。
ソフトウェアに組み込まれた世界のモデルが、あなたが実際に運営している世界と一致しない場合、選択肢は二つしかありません。
一つは、ビジネスをソフトウェアに合わせて変更することです。これは純粋な管理プロセスにおいては時折合理的ですが、競争上の優位性に関わる場合には危険です。
もう一つは、システム外で補完することです。つまり、補助的なスプレッドシート、手動での調整、例外処理、直前の上書きなどです。結果として、コアのソフトウェアは精巧な提案エンジンのような役割を果たし、実際の制御は人間やExcelファイルに戻ってしまいます。
汎用的なプランニング製品をあなたの固有の要件に合わせようとすればするほど、誰も完全に理解しきれない絡み合った設定が生じ、進化させるのが難しくなります。複雑さから逃れたのではなく、それをメタデータの中に埋め込んでしまったのです。
なぜプログラミング可能性は避けられないのか
設定だけでは不十分な場合、残るのはプログラミングです。
ここでの「プログラミング」という言葉はしばしば誤解されます。私は、すべてのプランナーがソフトウェアエンジニアになるべきだとか、すべての企業が最初から全てのスタックを構築すべきだと主張しているのではありません。単に、私が避けられないと信じる事実を述べているにすぎません：
もしあなたがサプライチェーンの意思決定をシステムに委ねたいのであれば、その意思決定がどのようなロジックで行われるのかを正確に表現できなければなりません。
そのロジックには以下が含まれます：
- 不確実性の取り扱い：需要、リードタイム、サプライヤーの信頼性、プロモーション、混乱など。
- 経済性のエンコード方法：品切れのコスト、過剰在庫のコスト、保管コスト、資本制約、サービスコミットメント、ペナルティ。
- 制約の執行方法：パッケージング、最低注文数量、トラックおよびコンテナの容量、賞味期限、代替ルール、規制上の制限。
- 相反する目標間でどのようにトレードオフが行われるか。
これらの要素はそれぞれあなたのビジネスに固有のものです。各要素は時間とともに変化し、また、どの設定オプションのカタログも予見できない形で相互に作用します。
このため、プログラミング可能性は単なるスタイルの好みではないと言えるのです。それは現実を認めることにほかなりません。問題は「プログラムすべきか」という問いではなく、「どこで、どのようなツールを使ってプログラムするか」という問いです。
スプレッドシートもまた一種のプログラミングです。彼らは、標準的なアプリケーションに収まらないロジックを現場の担当者が表現できるため、サプライチェーンにおいて非常に人気があります。残念ながら、スプレッドシートは拡張性に乏しく、ロジックの重複を招き、堅牢な自動化を実現しづらいのです。
汎用のプログラミング言語は何でも表現可能ですが、別の問題も伴います。もし、汎用スタックでサプライチェーン全体のインテリジェンスを構築しようとすると、気が付けば実質的にソフトウェア製品会社を運営している状態になってしまいます。実際のビジネスとはほとんど関係のない、データベース、分散コンピュート、インターフェース、セキュリティ、デプロイメントパイプラインなどを組み立て、維持しなければならないのです。
したがって、課題は、スプレッドシートの脆弱性と、ゼロから汎用プラットフォームを構築する手間を避けつつ、プログラミングを採用することにあります。
これがロカッドの技術的選択にどのように影響するか
2012年、私たちは意識的な選択をしました。すなわち、設定だけで箱から出してすぐに動くと謳う普遍的な「プランニング製品」を作ろうとはしないということです。
その代わりに、サプライチェーンの意思決定ロジックをコードとして表現できる環境を構築することに着手しました。その環境は、以下のようなものである必要があります：
- ビジネスの実際の複雑さをエンコードできる十分なパワーを持つこと。
- 理解しやすく、監査可能なほどコンパクトであること。
- 既存のトランザクションシステム上で、日常的かつ大規模に運用できること。
具体的には、これによりいくつかの原則に至りました。
第一に、ERPやその他のトランザクションシステムから得られるデータを、単なるレポート対象ではなく、原料として扱います。私たちは、本当の価値は、そのデータを具体的な意思決定、すなわち購買注文、在庫転送、生産スケジュール、価格および割引ポリシー、品揃えの決定に変換することから生まれると考えています。
第二に、その変換を、サプライチェーン専用に設計されたドメイン固有言語で書かれた一連のスクリプトとして表現します。具体的には、大規模な表形式データセット、確率的な需要、経済最適化などが含まれます。この言語は汎用のエンタープライズプログラミング言語ではなく、数値による意思決定レシピを簡潔かつ読みやすくすることを目的とした、特化型の環境です。
第三に、私たちは計算の出力をダッシュボードではなく、トランザクションシステムに適用可能な一連の提案アクションとすることを主張します。もし私たちの作業が変更された注文、在庫、価格に反映されなければ、生産環境に存在する意味はありません。
最後に、私たちはすべてを書き換え可能な形に構築します。もし世界が変われば、もしパンデミックが需要を変化させれば、もし新しい製品カテゴリーが予想外の振る舞いをすれば、新しい製品版を何年も待つのではなく、コードを迅速かつ安全に変更することを目指します。
これは、ソフトウェア製品にどんどんと汎用的な「機能」を蓄積しようとする考え方とは全く異なります。私たちは、すべての人に何かを提供しようとしているのではなく、特定の企業にとって本当に重要なロジックを表現するために使える、鋭利なツールを提供しようとしているのです。
主流の見解と私たちが分かれる点
サプライチェーン技術に対する主流のアプローチは、計画プロセスを標準化し、工業化するという合理的な目標に基づいています。統合されたスイート、あらかじめ定義されたベストプラクティス、ユーザーフレンドリーな設定が強調され、より迅速な導入と希少な技術スキルへの依存軽減が約束されます。
このアプローチが価値を発揮する状況もあります。特に、ビジネスがソフトウェアで前提とされる標準モデルに比較的近い場合や、主な目標が可視性、ガバナンス、基本的な調整である場合には。
私たちが分かれる点は、ある特定の質問に対する答えにあります：
実際に何をすべきかを決定する知性は、企業はどこに配置すべきでしょうか？
主流の答えは、パラメーター、ワークフロー、拡張機能によって調整され、ベンダーによって維持管理される、設定可能な製品の中にあるというものです。
ロカッドでの私たちの答えは、コンパクトでプログラム可能なレイヤーの中に、意思決定ロジックを所有し、現実の変化に応じてそれを変更できる小規模なチームが運用する形で配置するというものです。
この違いから、多くの実際的な結果が生じます。
製品中心の観点では、中心となる困難は適切な製品を選択し実装すること、そして組織をそのプロセスや機能と整合させることにあります。製品が導入されると、人々がダッシュボードを確認し、ワークフローに従い、入力を正しく行うことに注意が向けられます。
プログラム的な観点では、中心となる困難は、ビジネスの実際の経済性を反映し、不確実性を意味のある形で扱い、必要に応じて迅速に修正できる優れた数値レシピを構築し維持することにあります。ソフトウェアプラットフォームは、その取り組みをどれだけ支援できるかによって評価されます。複雑な制約を、ロジックがスパゲッティ化することなく表現できるでしょうか？昨日の意思決定を再実行して何が起こったのか理解できるでしょうか？新しいアイディアを安全に試行することができるでしょうか？
両アプローチとも、アルゴリズム、予測、最適化、魅力的なインターフェースを備えています。しかし、その違いは最終的にロジックを制御するのは誰か、そしてそのロジックがどれほど適応可能であるかにあります。
狭い道ではあるが、必要な道
プログラム的な道は、説明しやすいものではありません。「あなたはサプライチェーンの意思決定を表現するコードを持つことになる」というのは、「あなたは設定可能なベストプラクティスを備えたインテリジェントなシステムを持つことになる」よりも華やかさに欠ける印象です。また、明確な所有権、厳格なバージョニング、適切な計測、慎重な展開といった一定の規律も要求されます。
それでも、実際にサプライチェーンソフトウェアを約20年観察してきた結果、自動化を真剣に捉えるのであれば、実現可能な代替案は見いだせません。
もし、提案や可視化以上のことを行うシステムが欲しいのであれば、数十億ドル相当の商品を動かす意思決定に責任を持たせるシステムが欲しいのであれば、衝撃に耐え、新たに発見される制約に適応できるシステムが欲しいのであれば、私たちはロジックを正確に表現し、恐れることなくそれを修正できる手段を確保しなければなりません。
これこそがプログラミング可能性が提供するものです。
ロカッドが存在するのは、サプライチェーンが不透明な設定や硬直的な製品に任せるにはあまりにも重要であると信じているからです。それぞれのビジネスの混沌とした独特の現実を認め、サプライチェーンを運営する人々が自らの理解を真に機能する形でコード化するために必要なツールを提供するソフトウェアに値するのです。
この視点は、私たちが行った技術的選択とクライアントとの協働のあり方の両方を説明しています。知性が詰まっていると謳う箱を販売するのではなく、それを構築し、洗練し、維持し続ける方法を提供しているのです。
