なぜERPは決してあなたのサプライチェーンを運営しないのか
エンタープライズソフトウェアのベンダーは、自社のプラットフォームを企業の「デジタルバックボーン」と呼ぶのが好きです。サプライチェーンの世界では、このバックボーンは通常、ERPであり、MRP、WMS、TMS、CRMなどのシステムが補完的な役割を果たしています。多くの組織にとって、自明の次のステップはこう思われます：すでにERPが取引処理を行っているのであれば、なぜ意思決定も任せられないのでしょうか？いくつかの計画モジュールや予測エンジン、いくつかのAI機能を追加すれば、サプライチェーンはほぼ自律的に機能するはずです。
この逆のことを行うソフトウェアを約20年にわたり開発してきた結果、率直に申し上げて、従来の取引処理ベンダーは、サプライチェーンの意思決定システムを満足に提供する構造的適性を欠いているという結論に至りました。これは彼らの能力に対する不平ではなく、彼らが販売するソフトウェアのカテゴリ、直面している経済的インセンティブ、そして市場からの期待に関する問題です。
私はこの議論を自著「Introduction to Supply Chain」で詳しく論じていますが、ここではひとつの点を掘り下げたいと思います。それは、ソフトウェア環境において「脳が存在する場所」が、文献が認める以上に重要である理由です。
ソフトウェアに本当に求めていること
現代のサプライチェーンは単に箱を効率的に運ぶだけのものではありません。それは、毎日不確実性の中で賭けを行うことに他なりません。
コンテナを1個購入すべきか、3個購入すべきか？ プロモーションを遅らせるべきか、それとも前倒しすべきか？ 限られた在庫をヨーロッパに送るべきか、それとも米国に送るべきか？ このサプライヤーの最小発注数量を受け入れるべきか、あるいは交渉を引き延ばして供給途絶のリスクを冒すべきか？ いずれの決定も非対称な結果をもたらす小さな賭けに他なりません。あるミスは小さな代償で済みますが、他のミスは多大な損失を招き、月単位で影響が続く場合もあります。
50年前であれば、人々は台帳やスプレッドシートを頼りに、これらの賭けの大部分を頭の中で管理することができたかもしれません。今日では、中規模企業でさえ数万のSKU、数百の拠点、不安定なリードタイム、そして価格、天候、マーケティング、競合、供給途絶に反応する需要パターンを管理しています。これらの組み合わせは、人間の判断力だけでは対処しきれないほど複雑です。
そこで私たちはソフトウェアに助けを求めます。しかし「ソフトウェア」は一つのものではありません。典型的な企業では、非常に異なる3種類のシステムが共存しています。
まず第一に、トランザクション処理システム、すなわちERP、MRP、WMS、TMS、OMSがあります。これらの役割は、注文、受領、出荷、請求書、拠点間の移動など、発生したすべての事象を記録することです。それらは、洗練された台帳とワークフローの組み合わせです。信頼性、追跡可能性、権限管理、監査可能性が主な特性です。もし出荷が二重に行われたり、支払いが消失したりすれば、他のすべては無意味になってしまいます。
次に、レポートおよび分析システム、すなわちBIツール、ダッシュボード、KPIポータル、データウェアハウスから供給されるスプレッドシートがあります。それらの役割は、起こった事象、そして場合によっては起こり得る事象を要約・可視化することです。これらは人間が検査するために作られており、チャート、表、例外リスト、差異レポートなどが含まれます。
最後に、実際にはほとんど存在しないものがあります。それは真の意思決定エンジンです。つまり、すべての生データを取り込み、そのパターンを理解し、選択肢を評価し、具体的で監査可能な決定、すなわち購買注文、アロケーションの移動、生産スケジュール、価格変更、品揃えの変更を出力するソフトウェアのことです。これらの決定は定期的に自動的に生成され、その後、非常に一貫性のある迅速なプランナーが作業を行ったかのように、トランザクションシステムに書き戻されるべきです。
主流の見解はこれら三つの役割を混同しがちです。もしERP「バックボーン」がすでにデータを統合しプロセスを実行しているなら、当然計画や最適化も可能なはずです。そうでなければ、別の汎用プラットフォーム、つまり「デジタルコア」、「コントロールタワー」、または「統合プランニングスイート」が登場するでしょう。文献では、ERPが企業情報処理の中核であり、企業のバックボーンであると説明され、その同じプラットフォームの自然な拡張としてサプライチェーンの計画と実行が提示されるのが一般的です。
理論上は魅力的に見えます。しかし実際には、ここから物事がうまくいかなくなるのです。
トランザクションベンダーが意思決定エンジンの構築に不向きな理由
この不整合を理解するためには、ブランド名から一歩引いて、ERPやその関連システムが実際に何であるかを見つめ直すことが有用です。
本質的に、これらのシステムは、誰が何を、どの順序で変更できるかという厳格なルールを持つ、大規模なマルチユーザーデータベースです。これらは、一度に発生する多くの小規模でシンプルで整理された操作、例えば注文の登録、請求書の投稿、受領の確認などに最適化されています。ERPの教科書でこれらが企業の「バックボーン」と呼ばれるとき、文字通り、日々の業務の神経と血管を担っているという意味です。
対照的に、本物の意思決定エンジンは、何千もの軽量なクリック操作に最適化されているわけではありません。重い思考処理に最適化されています。
膨大な量のデータを、しばしば複数のシステムにまたがって取り込む必要があります。単一の予測を外挿するだけでなく、数多くの可能な未来を模索する必要があります。サービスレベルやリードタイム目標だけでなく、経済的な基準に従って選択肢を評価する必要があります。場合によっては高コストとなる計算、つまり確率モデル、シミュレーション、組み合わせ最適化を実行する必要もあります。そして、なぜその日にこの商品を20パレット購入したのか、15パレットまたは購入しなかったのかというように、後で監査可能な方法でこれらすべてを行う必要があるのです。
これはプログラミング言語や巧妙な最適化の問題ではありません。それは、異なるランタイムプロファイル、エンジニアリング上のトレードオフ、および異なる形態の説明責任の問題です。この種のエンジンを、日々の請求書や倉庫管理画面を動かす同じ環境に組み込むことは、都市バスにジェットエンジンを搭載するようなものです。それは単なるオーバースペックではなく、バスの本来の役割を妨害するものなのです。
ここから、いくつかの構造的な問題が浮かび上がります。
最初の問題は運用上の問題です。取引処理プラットフォーム上で重い分析や大規模な最適化ジョブを直接実行しようとすると、業務の遅延を避けるために分析作業を制限するか、人間が作業を行おうとする際の応答時間を損なうリスクを負うことになります。「インテリジェンス」を組み込むほどに、システムの主要な使命、すなわち取引を失わず、ユーザーをブロックしないという点が劣化していくのです。
二番目は意味論的な問題です。現代の企業は、単一のモノリスで運用されることはほとんどありません。財務および主要なオペレーションにはERP、倉庫にはWMS、輸送にはTMS、顧客対応にはCRM、そしてe‑コマースプラットフォーム、場合によっては製造や小売専用のシステムが存在します。それぞれのシステムは固有の語彙と独自の真実を持っています。しかし、有用な意思決定エンジンは、それらすべてを横断して見る必要があります。とはいえ、ERPベンダーの自然な傾向は、自社のスキーマを宇宙の中心と見なすことにあります。他のすべては、情報の一部しか取り込めなかったり、無視されたりするのです。
三番目は経済的な問題です。大手の取引処理ベンダーは、主にライセンス、ユーザー数、モジュール、およびストレージに対して支払いを受けており、クラウド時代では、サブスクリプションの層や使用量も加わります。彼らは、安全に自動化できる決定数や、P&Lに還元されるキャッシュの量に応じて報酬を得るわけではありません。実際、真に効果的な意思決定エンジンは、「プランナー」ユーザー数を削減し、多くのワークフローを簡素化するでしょう。しかし、これは彼らの価格モデルが報酬として設計されているものではありません。
これに認証エコシステムを重ね合わせると、状況はさらに明確になる。例えば、APICS/ASCM CPIMプログラムは計画と在庫管理のグローバルスタンダードとして明示され、研修資料ではERPシステムがこの知識体系から派生した業務ルールを組み込んでいることが公然と記されている。
言い換えれば、標準的な計画ロジックはERPの内部に存在すると仮定されている。ベンダーはそれをエンコードすることが求められ、実務家はそれを設定し従うことが求められる。その使命は、実務を正典に合わせることであり、ソフトウェアアーキテクチャや意思決定の経済性を再検討することではない。
最後に、文化がある。記録保持システムの構築は、安定性、下位互換性、およびエッジケースへの対応を重んじる特定のエンジニアリングマインドセットを引き寄せ、報酬を与え、昇進させる傾向がある。何十年にもわたり、これらのシステムは機能、モジュール、カスタマイズ、統合の層を積み重ねていく。非常に高い能力を発揮する一方で、極めて複雑になる。別の計画モジュールやAI機能を追加することは、何かを削除するよりも文化的に容易である。その結果、既に壊れやすいワークフローに織り込まれた、ますます増大する構成画面とパラメータの塊となる。
このマシンに自らを鋭く、自己主張の強い意思決定エンジンとして生まれ変わらせることを求めるのは、最良でも楽観的な考えである。
主流のナラティブ、そのままの表現で
ベンダーの資料、ホワイトペーパー、そして多くの学術・専門文献を読めば、ほとんど同じ話がほんのわずかな変化を伴って繰り返されていることに気付くだろう。
ERPは、すべてのデータとプロセスを統合する統一プラットフォームとして提示され、調達、在庫、受注処理、流通を「調和」させながら、分析や計画ツールを組み込んでいる。それは、金融から製造、サプライチェーンに至るまで全てを支えるビジネスのソフトウェア基盤、すなわち「デジタルコア」として説明される。この基盤の上に、予測分析による需要予測、シナリオモデリング、統合ビジネスプランニングなど、ますます高度な機能が約束される。
並行して、オペレーションマネジメントの正典はメンタルモデルを提供する。すなわち、CPIMの知識体系、S&OPフレームワーク、安全在庫の計算式、MRPロジックである。これらはベストプラクティス、試験シラバス、成熟度モデルとして体系化されている。暗黙の約束は単純である。適切なERPを実装し、これらの基準に従って設定し、プランナーを適切に訓練すれば、サプライチェーンは期待通りに機能するということだ。
もし現実がその約束に応えない場合、よくある説明は、データ品質、チェンジマネジメント、プロジェクトの範囲、経営層の支援不足、訓練の不十分さといったものに帰される。対策は常に同じである。すなわち、より慎重な実装、より規律あるプロセス、標準知識体系のより徹底した採用である。
ほとんど疑問視されない点に注目してほしい。それは、サプライチェーンの「脳」が受注記録や請求書印刷を行う同じシステム内に存在すべきであるという前提である。
現場で実際に起こっていること
現場では、ほとんどの組織が業界や地域を問わず、憂鬱なほど一貫したパターンに陥る。
トランザクションシステムは、その役割を比較的うまく果たす。注文が流れ、在庫が移動し、請求書が発行され、財務決算が行われる。多少の癖や不満は常にあるが、概ね帳簿は整っている。
このコアの周りでは、レポーティングが急増する。BIツールはデータウェアハウスに接続し、そこからERPやその周辺システムがデータを抽出する。各チームはダッシュボード、スコアカード、コックピット、そしてコントロールタワーを構築する。プランナーはこれらの画面を操作し、不一致を調整し、データをスプレッドシートへエクスポートし、「調整済み」数値を再インポートすることに、ますます多くの時間を費やす。
多くのシステムには計画および最適化モジュールが実際に存在する。これらは予測を生成し、補充量を提案し、警告を発する。しかし、大部分の重い作業は手動のままである。予測は上書きされ、提案された注文は一件ずつ「レビュー」される。例外リストは作業日中に誰も合理的に片付けきれないほど長くなるため、人々はローカルなヒューリスティクス、すなわち「これらの指標は信頼し、あれは無視し、このベンダーを常に優先し、あの商品には手を出さない」といった方法を編み出す。
自動化は大部分がトランザクションシステム内の条件付きロジックという形態をとる。例えば、在庫が一定水準を超えていればこの注文をリリースし、下回れば例外キューに保留する。遠目には知的な動作に見えるかもしれないが、近くで見ると、脆弱なルールと人間の対処戦略の組み合わせにすぎない。
私は時折、この状況を「ペーパーワークとしての自動化」と呼ぶ。システムは精巧で忙しく、場合によっては印象的であっても、実際に経済的重みを持つ意思決定に全権を委ねることはほとんどない。どこかで必ず「OK」をクリックする人間が求められるのだ、それが単なる儀式になっていたとしても。
これは成熟した意思決定エンジンのあり方ではない。
別の関心の分離
サプライチェーンが不確実性下での経済的意思決定の毎日の実践であるという考えを真剣に受け止めるならば、ソフトウェアの構成はそれを反映するように設計されるべきである。
その構成において、トランザクションシステムは得意分野である、過去に起こった事象や現在確定している事実の権威ある記録としての役割を引き続き果たすだろう。そのスキーマやワークフローは進化を続け、依然として重要であり続ける。しかし、我々はそこに賢さを求めるのをやめる。
レポーティングシステムは、現状を視認し、理解し、議論するという得意分野を果たし続ける。優れたダッシュボードや分析ツールは引き続き非常に価値がある。しかし、可視化と最適化を混同するのはやめる。
そして、別途、専用の意思決定エンジンを導入する。
このエンジンは、注文、在庫状況、能力、リードタイム、価格、制約条件といった、関連するすべてのトランザクションシステムから定期的に生データのフィードを受け取る。このデータがERP、WMS、TMS、またはその他のシステムに由来するかは問題ではない。これらの事実から一貫した世界観を再構築し、需要と供給における不確実性を明示的に認識し、期待利益、在庫切れのリスク、陳腐化コスト、制約資源における機会費用といった経済的影響に基づいて代替アクションを評価する。
このエンジンの出力はダッシュボードではなく、提案されたアクションの流れである。例えば、「その日付にそのサプライヤーからそのSKUをこれだけ購入する」、「今夜この倉庫からあの倉庫へこれらのパレットを出荷する」、「この商品の価格を2%引き上げる」、「来月にわたってそのバリアントを段階的に廃止する」といった具合である。各アクションには、必要に応じて人間が監査できるよう、使用されたデータ、推論されたパターン、実行されたトレードオフについての十分なコンテキストが付随している。
重要なのは、これらのアクションが明確に定義されたインターフェースを通じてトランザクションシステムに書き戻されることである。発注書はプランナーが入力したかのようにERPで作成され、在庫転送は倉庫管理者が開始したかのようにWMSに現れ、価格変更は明確な有効日とともに価格システムに反映される。
人間はループから消え去ることはありません。彼らの役割は変化します。彼らは数値レシピの管理者となり、どのコストを含めるべきか、リスクをどのように評価するか、どの制約が現実的でどのシナリオが許容されるかを決定します。彼らはエンジンが出力するすべての行を細かく管理するのではなく、その動作を検証し洗練させます。
このアーキテクチャは、ERP中心の物語に長く浸っていた場合にのみ、エキゾチックに聞こえるものです。ソフトウェアエンジニアリングと経済学の視点からすれば、これは単に関心事の明確な分離、すなわち事実のための元帳、理解のためのダッシュボード、意思決定のためのエンジンなのです。
主流の見解にどのように対抗するか
この観点から見ると、主流の語り口は「間違っている」というよりも不完全なのです。
統合されたトランザクションのバックボーンを求めるのは全く合理的なことです。企業は断片化された会計、在庫、製造システムから統合ERPへの移行によって大きな恩恵を受けました。また、優れたレポートを求め、業界全体で用語やプロセスを標準化することも合理的です。CPIMのような取り組みは、人々に共通の言語と基本的なツールキットを提供する上で重要な役割を果たしてきました。
私が主流と意見が分かれるのは、トランザクションのバックボーンに、より多くの計画モジュール、より多くの予測機能、より多くの分析、そしてより多くの構成オプションを追加し続ければ、最終的には効果的な自動サプライチェーンの意思決定に到達すると暗黙の前提している点にあります。
私はこの収束が起こるとは信じていません。
「脳」が、記録保持、役割ベースのワークフロー、そして一般的なベストプラクティスを主な使命とするシステム内に存在することが期待される限り、私たちは印象的なインターフェースと控えめな自動化のパターンにとどまるでしょう。プランナーは、警告リストを手直しするだけで、その警告を生み出す経済ロジックを作り上げることに時間を費やす組織を見続けることになるでしょう。
代替案は、ERPを捨てたり、確立された手法を無視することではありません。それらを、本来あるべきもの――必要なインフラであり貴重な職業遺産であるものの、実際の意思決定が行われるべき場所ではない――として扱うことなのです。
この違いを認めれば、より正直な議論が可能になります。私たちはトランザクションベンダーに対して「AI搭載の最適化」ではなく、優れた元帳とクリーンなインターフェースを求めることができます。BIチームにも、制御室を装うアニメーションダッシュボードではなく、シンプルで正確な現実の姿を求めることができます。そして、私たちは意思決定エンジン―それを構築し運用する人々―に対して、夜間の無人の意思決定、現金における説明責任、継続的な改善といった、より高い基準を要求することができるのです。
これは、Lokadで長年にわたって追求してきた方向性です。それが唯一の道ではありませんが、サプライチェーンが実質的にソフトウェアによって制約される場合、ソフトウェアの「脳」をどこに配置するかが決定的な違いを生むというシンプルな観察から始まるのです。
