SAP IBP、o9、Kinaxis — デモが見せてくれないもの

デモは完璧だろう。コンサルタントは、あなたの業界向けテンプレートで事前構築されたテナントを持って現れる。財務計画と運用計画をリアルタイムで調整するダッシュボード、POSデータに応じて調整されるデマンドセンシングモジュール、3つの混乱シナリオに対して同時に供給計画をストレステストできるシナリオ比較画面を見せてくれる。スライドには競合他社のロゴと「あなたの業界で200社以上の顧客」というフレーズが載る。数字は非の打ちどころがないだろう。

これのどれも不誠実ではない。プラットフォームはそのすべてを行う。デモが見せてくれないのは、そのすべてに先立つ18か月のデータ調和作業、それを動かし続けるために必要な社内人員、そして稼働開始から3年後にあなたの組織が実際に使うものと、プラットフォームができることとの間のギャップだ。

そのギャップがどう見えるか――そしてサインする前に何を問うべきか。

3つのプラットフォーム、マーケティング抜きで

SAP IBP――Integrated Business Planning――は、SAPのS/4HANAエコシステム内のS&OPおよびサプライ計画モジュールだ。HANAのインメモリデータベース上で動作し、大規模データセットにおいて本物のスピード上の優位性をもたらす。アーキテクチャはモジュール式だ。Supply、Response & Supply、Demand、Inventory、Sales & Operationsは別々のライセンスだ。狭く始めることができる。落とし穴は、モジュールが別々に価格設定されており、本当の価値はそれらを横断した統合から生まれるということだ――つまりあなたの「スターター」導入には、製品アーキテクチャに組み込まれたアップセルの経路が最初から存在する。

中堅製造業(アクティブSKU 5,000~15,000、プランナー10~15人)向けの価格は、ソフトウェアのみで年間38万~52万ドルの範囲に収まる。Big Fourパートナーによる導入は通常18~24か月かかり、初年度ソフトウェアコストの1.5~2.5倍だ。IBPの自然な居場所は、すでにSAPに深く根ざした企業だ――あなたのERPがS/4で、マスターデータがSAPに置かれているなら、統合の議論は本物だ。あなたのERPがOracleやカスタムスタックなら、あなたは維持コストが毎年複利で増える統合レイヤーを追加していることになる。

Gartnerの2024年版Magic Quadrant for Supply Chain Planningは、IBPをリーダーではなくチャレンジャーに位置づけた。理由は、機能的な深さは強く、SAPエコシステムへのフィットも強いが、ピュアプレイの競合と比べて使いやすさと展開スピードで弱いというものだ。Gartner Peer Insightsにおける顧客満足度スコアは示唆的だ――悪くはないが、「価値実現までの時間」で一貫してKinaxisを下回っている。

Kinaxis Maestro(旧RapidResponse)は異なるアーキテクチャ原則で動作する。コンカレントプランニングだ。逐次的な最適化実行――需要計画が供給計画に流れ込み、それが財務計画に流れ込む――を行うのではなく、Maestroはすべての計画を同時にメモリ上で維持し、ほぼリアルタイムで変化をそれらに伝播させる。サプライヤーが部品不足を確認したとき、Maestroは計画全体への再伝播のために夜間バッチジョブをキューに入れたりしない。それは需要、供給、財務にわたって即座に影響をカスケードさせ、意思決定の選択肢を表面化させる。

このアーキテクチャは本物に差別化されている。同時に本物に高価でもある。ユーザー数とモジュール範囲に応じて年間10万~50万ドル以上、導入倍率も同様に1.2~1.8倍だ。Kinaxisは2024年のGartner MQでリーダーであり、そのピアレビュースコアは、ユーザー満足度と計画サイクルのスピードにおいて3社の中で一貫して最も高い。その弱みはSAPとは正反対だ。計画の俊敏性には強いが、計画の下流にあるすべてに対してERPがシステム・オブ・レコードである企業にとっての、S/4への深い統合には弱い。

コンカレントプランニングの提案が最も重要になるのは、供給のボラティリティが高く、顧客リードタイムが短く、計画サイクルが現在週次以上かかっている企業だ。バッチのウィンドウがボトルネックになっているからだ。あなたの計画サイクルが日次かそれ以上速いなら、Kinaxisのアーキテクチャは制約から時計を取り除く。あなたの計画サイクルが月次で、計算時間ではなく人間の整合によって駆動されているなら、実際にはそのアーキテクチャ上の優位性を目にすることはないだろう。

o9 Solutionsは高価格帯で競争する。フォーチュン500、複雑なグローバルネットワーク、マルチエンタープライズ計画だ。その差別化要因はEnterprise Knowledge Graphだ――顧客、SKU、サプライヤー、施設、契約の間の関係をマッピングする統一データモデルであり、プランナーはグラフデータベースに問い合わせるように計画に問い合わせることができる。「レポートを実行する」のではなく、「EMEAにおけるこのSKUの二次サプライヤー依存関係は何か?」というように。

o9は2023年のGartner MQでビジョナリーだった。2024年にはニッチプレイヤーに降格された。レポートは、o9が顧客基盤を急速に拡大する中での実行上の懸念を理由として挙げている。顧客レビューはKinaxisより二極化している。能力の幅では高いスコアだが、導入経験とサポートの応答性では低いスコアだ。価格はオーダーメイドで非公開だが、業界のベンチマークはエンタープライズ層でKinaxisより上に位置づけている。

Figure

デモが答えられない問い

どのプラットフォームも、統制されたデモ環境ではあなたの現在のプロセスより優れた計画を生み出す。デモテナントにはクリーンなマスターデータがある。一貫した単位、重複しない品目番号、2017年のシステムデフォルトではなく現実を反映したサプライヤーリードタイムだ。あなたのテナントにはそれがない。

サプライチェーン計画ソフトウェアの根本的な制約はアルゴリズムではない。データだ。計画は、それを制約するマスターデータと、それに入力される実績と同じくらいの良さしかない。私が見てきた、ビジネスケースを下回った導入はすべて、同じ根本原因に行き着いた。計画ツールはデータが準備できる前に展開され、ソフトウェアが稼働した後にプロジェクトの予算が尽きたため、データは完全にはクレンジングされなかった。

どのプラットフォームの計画ロジックを評価する前にも、次の4つの問いに照らしてマスターデータを監査してほしい。

1. リードタイムの精度。 システムのリードタイムは、現在のサプライヤーのパフォーマンスを反映しているか、それとも3年前の契約リードタイムか。ほとんどの導入で、答えは契約リードタイムだ。システムのリードタイムと実際のリードタイムのギャップは、計画誤差の単一最大の要因であり、どのプラットフォームもそれをアルゴリズムで直しはしない。
2. 単位の一貫性。 すべてのインプット――需要予測、供給計画、在庫ポジション――は同じ単位で表現されているか。混在した単位はマルチERP環境で一般的であり、システムの数量を信用しないプランナーによるオーバーライドを生む。
3. BOMの完全性。 個別受注生産の製造業者にとって、稼働中のすべての完成品が最新かつ正確な部品表でカバーされているか。供給計画はBOM展開の上に構築される。不完全または古いBOMは、どんな最適化が実行される前から構造的に間違った計画を生む。
4. サプライヤーのキャパシティデータ。 期間ごとに確認済みのサプライヤーキャパシティがあるか、それとも無制約のサプライヤー産出量に対して計画しているか。ほとんどの企業は無制約で計画し、実行中に制約を発見する。システムに存在しない制約をプラットフォームがモデル化することはできない。

サインする前に問うべきこと

ベンダー交渉で問う価値のある質問は、フィーチャーマトリクスについてのものではない。失敗モードについてのものだ。

あなたのデータプロファイルに合ったリファレンスを求めてほしい。 あなたの業界ではなく、あなたのデータの複雑さだ。もしあなたが14の製造拠点にまたがる8万件のアクティブSKUを持ち、6つのERPが計画レイヤーに供給しているなら、稼働開始から3年以上経過した、同様のプロファイルを持つ顧客と話をさせてほしいと頼んでほしい。初期採用者はケーススタディに登場する人々だ。3年目の顧客が、定常状態がどう見えるかを教えてくれる。

導入後、誰がモデルを所有するのか問うてほしい。 ほとんどの導入はシステムインテグレーターによって提供される。SIが去ると、モデルは社内チームの手に残る。具体的に問うてほしい。同等の顧客が、このプラットフォームを定常状態で運用するのに何人の社内FTEを必要とするか。その答えは検証可能であるべきだ。「パワーユーザー2名とパートタイムのITリソース」と「専任プランナー4名とフルタイムのITアーキテクト」はどちらも正当な答えだ。前者は複雑な導入にとっては楽観的すぎ、後者は高価だが正直だ。どちらの数字を提示されても、最初の2年間についてはそれを2倍にしてほしい。

チェンジマネジメントの範囲について問うてほしい。 サプライチェーン計画ツールは、プランナーが毎日どう働くかを変える。プラットフォームはバックグラウンドシステムではない。プランナーの主要なインターフェースだ。導入計画に、名前のついた社内オーナーを持つ構造化されたチェンジマネジメントのワークストリームが含まれていないなら、その導入は、プランナーがその中で働くのではなく回避するシステムを生み出す。これは仮説ではない。私が見てきた「失敗した」計画導入のほとんどは、技術的には予定通り予算内で提供されていた。それらが失敗したのは、プランナーがシステム・オブ・レコードとしてExcelを使い続け、新しいプラットフォームをS&OPデック用のレポートを生成するためだけに使ったからだ。

正しい順序

プラットフォームは本物であり、価値は手に入る。それを捉えるための順序は次のとおりだ。

1. 現在のプロセスをベースライン化する。 予測精度を各層で測定し、計画サイクルタイムを測定し、現在のプロセスにおける上位5つの手作業の回避策を特定する。これがあなたのベンチマークだ。どのベンダーも、自社のプラットフォームがそれぞれにどう対処するかを具体的に示せるはずだ。
2. まずデータをクレンジングする。 少なくとも、稼働開始後ではなく稼働開始前に、データクレンジングのワークストリームを定義し予算をつけてほしい。それを導入と並行するトラックとしてスコープし、稼働開始後のクリーンアップとしてではなく。
3. 制約されたスコープでパイロットする。 1つの製品ファミリー、1つの地域、1つの製造拠点。ライセンスをスケールさせる前に、あなたのデータに対してコンセプトを証明してほしい。ほとんどのベンダーは、成功すればフルライセンスに転換する有償パイロットに同意するだろう。もし同意しないなら、それは何かを物語っている。
4. 何をやめるかを定義してほしい。 古いプロセスが停止されるとき、どんな計画ツールもより速く採用される。プランナーがレガシープロセスを並行して使い続けられるなら、彼らはそうするだろう。特に新しいプラットフォームが初期展開の避けられない荒波に遭遇したときには。カットオーバーの日付を定義し、それを守ってほしい。

プラットフォームはボトルネックではない。あなただ。問題は、あなたの組織がデータを直し、プロセスを変え、購入したツールを運用する社内能力を築く規律を持っているかどうかだ。ベンダーは営業と導入の段階では助けになるだろう。彼らが去った後に残る能力は、完全にあなた自身が築くものだ。

---

出典

• Gartner. (2024). Magic Quadrant for Supply Chain Planning Solutions. gartner.com
• Gartner Peer Insights. (2024). Reviews for Supply Chain Planning, 2024. gartner.com
• Lee, H.L. (2004). The Triple-A Supply Chain. Harvard Business Review.
• Lapide, L. (2005). Sales and Operations Planning Part I: The Process. Journal of Business Forecasting.
• SAP. (2024). SAP IBP Product Overview. sap.com
• Kinaxis. (2024). Maestro Platform Overview. kinaxis.com
• o9 Solutions. (2024). Enterprise Knowledge Graph. o9solutions.com