ITトレンドがおすすめする製品・サービス
- ■構築の進め方別
- 自社の業務にあわせた設定やカスタマイズに対応する需要予測システム：PlanNEL、AI需要予測・運用サービス「Deep Predictor（ディープ・プレディクター）」、LTV-Zaiko、α-発注
- 導入前の事前検証に対応する需要予測システム：α-発注
- 業務の一部から段階的に導入できる需要予測システム：Demand Solutions DSX
- 導入後の運用支援を受けられる需要予測システム：PlanNEL、AI需要予測・運用サービス「Deep Predictor（ディープ・プレディクター）」、LTV-Zaiko、α-発注
- ■既存システムとの連携・業務活用別
- APIで他システムと連携できる場合：PlanNEL、AI需要予測・運用サービス「Deep Predictor（ディープ・プレディクター）」、LTV-Zaiko
- 受注システムやECカートと標準連携できる場合：LTV-Zaiko
- 予測をもとに発注量の算出や発注判断を支援する場合：AI需要予測・運用サービス「Deep Predictor（ディープ・プレディクター）」、LTV-Zaiko、α-発注、Perswell
需要予測システムの構築目的を業務の指標に落とす
需要予測システムの構築は、予測の精度を上げること自体がゴールではありません。業務の何を改善したいのかを、測れる指標で表すところから始めます。
欠品率や在庫日数などの目標設定
需要予測の効果は、欠品による機会損失の減少や、在庫の圧縮、廃棄の削減などで表れます。構築の前に現状の数値を記録し、改善の目標値を決めておきます。
目標の数値が曖昧だと、構築後に効果を確かめられません。経営層や現場の関係者と共有できる形にしておくと、プロジェクトの方向性がそろいます。
予測を使う業務の特定
予測の結果を、発注、生産計画、人員配置、販促の計画のうち、どの業務で使うのかを決めます。使う業務によって、必要な予測の期間や粒度が変わります。
複数の業務で同時に使おうとすると、要件が膨らみます。最初は効果の大きい業務を一つに絞り、成果を確かめてから広げる進め方が現実的です。
関係部署と責任者の決定
需要予測は、営業、購買、生産、物流など複数の部署に関わります。各部署の代表者をプロジェクトに加え、最終的な判断を行う責任者を決めておきましょう。
責任者が不明確だと、部署間の意見の食い違いが解消されず、進行が止まる場合があります。意思決定の場と頻度も、はじめに決めておくと安心です。議事録を残して、決定の経緯を後から追えるようにしておきましょう。
需要予測の要件定義で決める連携範囲
要件定義では、予測に使うデータと、結果を戻す先を明らかにします。この段階の抜けが、後の追加費用や遅れの原因になることがあります。
予測に使うデータの棚卸し
販売実績、在庫、価格、販促、天候など、予測の材料にできるデータを洗い出します。どのシステムに、どの期間分が、どの形式で保管されているかも、あわせて確認します。
データが足りない、または形式がばらばらな場合は、整備の作業を計画に含める必要があります。外部の事業者に依頼する場合は、作業の範囲と費用も確認しておきます。見積もりには、データの整備にかかる工数が含まれているかも見ておきましょう。データの整備に想定以上の時間がかかることは珍しくありません。
連携するシステムと更新の頻度
基幹システムからのデータの取り込みと、予測結果を発注システムなどへ戻す連携の方式を決めます。毎日更新するのか、週に一度かによって、設計の難しさが変わります。
連携先の仕様や、変更を担当する部署の確認も欠かせません。連携先のシステムが古い場合は、接続の方法が限られることもあります。その場合は、ファイルを介した連携など代替の方法を検討します。
利用者の範囲と権限の整理
誰が予測を見て、誰が修正し、誰が承認するのかを整理します。店舗や拠点ごとに閲覧の範囲を分ける必要がある場合は、要件として明記します。
権限の設計が後回しになると、本番の直前に手戻りが発生しやすくなります。修正の履歴を残す要件も、このタイミングで検討しておきましょう。履歴の保存期間も決めておくと、後の確認に役立ちます。
PoCで確かめる需要予測の使いどころ
PoCとは、本格的な構築の前に、小さな範囲で実現性と効果を試す検証のことです。需要予測では、自社のデータで予測が実用に足りるかを確かめる役割があります。
対象を絞った検証の設計
PoCでは、品目や拠点を限定し、期間を決めて検証します。売れ行きの安定した品目と変動の大きい品目の両方を含めると、予測の向き不向きが見えてきます。新商品のように過去データのない品目は、別に扱う方針を決めておくとよいでしょう。
検証の期間が短すぎると、季節の変動をとらえられません。過去のデータを使った検証と、実際に運用して確かめる検証を組み合わせるのが有効です。
現行の予測との比較
PoCの結果は、現在の担当者の予測や、単純な前年同期の実績と比べて評価します。システムの予測だけを見ても、導入の価値は判断できません。
誤差の大きさだけでなく、欠品や在庫の量など業務上の結果で比べると、判断しやすくなります。結果の悪かった品目については、原因も調べておきましょう。データの不足が理由なのか、手法があわないのかで、次の対応が変わります。原因を切り分けておけば、本番での改善策も立てやすくなります。
本番へ進むかの判断基準
PoCを始める前に、本番へ進む基準を決めておきます。例えば、決めた指標が目標に届いたか、現場が使える形になったかを基準にします。
基準がないと、結果に関わらず本番へ進んでしまう場合があります。期待した効果が出ないときに、範囲を絞り直すか、見送るかの方針も事前に話し合っておきます。見送る場合の費用の扱いも、契約の段階で確認しておくと安心です。PoCのみで終了できる契約かも確かめておきます。
ITトレンドでは、最新の製品・サービスを多数比較・掲載しています。まず資料請求して、さまざまな製品の機能や特徴を比較してみてください。忙しい業務時間内でも、各社に問い合わせる手間なく、たった1回の入力（約60秒）で需要予測の一括資料請求が可能です。浮いた時間で、じっくりと製品を比較検討し進めましょう。
本番構築のテストと切り替え
PoCで効果を確かめたら、本番環境の構築や設定を進めます。既製のクラウド型製品では、サーバの構築よりもデータ連携や業務にあわせた設定が中心になる場合もあります。この段階では、予測精度に加え、実際の業務で問題なく運用できるかを確認しましょう。
受け入れテストで見る範囲
実際のデータを流して、予測が出るか、連携先に正しく結果が渡るかを確認します。データの欠損や、想定外の値が入った場合の動きも試しておくと、本番での不具合を減らせます。
テストには、現場の担当者にも参加してもらいます。画面の見やすさや操作の流れは、使う人でなければ気づけない点が多くあります。テストの結果は一覧にして、対応の状況を関係者で共有しましょう。
並行運用による切り替え
従来の方法と新しいシステムの予測を、しばらく並べて使う並行運用が有効です。両者の差を確かめながら、新しいシステムを使う範囲を広げていけます。
並行運用の期間は、発注のサイクルを複数回含む長さにします。切り替えの基準と、問題が起きたときに元へ戻す手順も決めておきましょう。切り替えの時期は、繁忙期を避けると負担を抑えられます。
利用者への説明と研修
現場の担当者が予測の見方と修正手順を理解していないと、システムは使われません。操作の説明に加えて、予測の根拠や限界についても伝えます。
予測が外れる場合があることを、はじめに共有しておくと、現場の信頼を保ちやすくなります。質問を受け付ける窓口も、稼働の直後は手厚く用意しましょう。よくある質問をまとめた資料を配ると、問い合わせの負担も軽くなります。
構築後に残る作業を計画へ入れる
構築が終わっても、予測システムの仕事は続きます。稼働後の作業を計画に含めておかないと、精度が徐々に下がるおそれがあります。
精度の監視と再学習の担当
需要の傾向が変わると、予測の精度は低下する場合があります。誤差を定期的に確認し、必要なときにモデルを見直す担当者と周期を決めておきます。
この作業をベンダーに依頼するのか、自社で行うのかで、費用と体制が変わります。構築の契約の段階で、稼働後の支援の範囲も確認しましょう。支援の対応時間や、追加費用が発生する条件も見ておきます。
データやマスタの更新運用
新商品の追加や廃番、価格の改定、店舗の増減など、予測の前提は日々変わります。これらを予測システムへ反映する手順と担当者を決めておきます。
更新が遅れると、予測の精度に影響します。更新の漏れを検知する仕組みや、確認の手順があると安心です。更新の担当者が休んだ場合の代わりの人も決めておきましょう。
追加の機能や対象の拡大
効果が確かめられたら、対象の品目や拠点を広げ、機能を追加していく流れが考えられます。拡大する際は、費用と体制がどう変わるかを、最初の構築の段階から見通しておきます。
将来の拡大に備えて、拡張しやすい構成かを確認しておくと、後の選択肢が広がります。
構築の進め方で比べる需要予測システム一覧
需要予測システムの構築時に確認したい、既存システムとの連携やカスタマイズ、導入前の検証、運用支援などの特徴を一覧にまとめました。自社で対応する範囲とベンダーに任せる作業を整理しながら比較しましょう。
| 製品名 | 特徴 |
|---|---|
| PlanNEL | 複数AIモデルによる予測と精度評価、学習データの補正に対応。API連携や個別カスタマイズも可能 |
| AI需要予測・運用サービス「Deep Predictor（ディープ・プレディクター）」 | 基幹システムやERPとのAPI連携に対応。データ処理の自動化や専任担当者による運用支援が特徴 |
| LTV-Zaiko | 受注システムやECカートとの標準連携に対応。API連携や導入企業向けカスタマイズも可能 |
| α-発注 | AI導入効果の事前検証や定期チューニングに対応。発注リストの自動作成や在庫異常の検知も支援 |
| Demand Solutions DSX | 需要予測・需給計画・生産スケジューラー・S&OPの４モジュールを統合。必要な機能から段階的に導入可能 |
| Perswell | 機械学習と外部データを活用した需要予測に対応。発注数や在庫量の自動算出を支援 |
構築時の連携と調整で比べたい製品
既存システムとの連携やカスタマイズ、導入前の検証など、需要予測システムの構築を支援する製品を紹介します。自社の業務要件への対応範囲や、導入後のサポート体制もあわせて比較しましょう。
PlanNEL
- 販売実績を元に複数AIモデルで需要を予測し、精度の高い計画立案
- 予測精度を定量評価し、採用すべきモデルと改善ポイントを確認
- 外れ値などの影響を補正した学習データで、予測精度を高める
ザイオネックス株式会社が提供する「PlanNEL」は、需要予測モデルの選定や精度評価、学習データの補正を支援するSCMシステムです。ProphetやRandom Forestなど複数のAIモデルを利用でき、MAPEやWAPE、RMSEによる精度比較にも対応。欠品や特売、外れ値などの影響を補正し、補正理由も記録できます。API連携に対応し、エンタープライズプランでは個別カスタマイズも可能です。オンプレミス・クラウド・SaaSから提供形態を選べ、導入支援パートナーも用意されています。
AI需要予測・運用サービス「Deep Predictor（ディープ・プレディクター）」
- 予測から発注量算出などのアクションまで自動化
- 数十万SKU・外部データに対応した高精度な需要予測
- データ処理から基幹システム連携まで自動化
AI CROSS株式会社が提供するAI需要予測・運用サービス「Deep Predictor（ディープ・プレディクター）」は、予測データの処理から基幹システムとの連携までを自動化するクラウド型サービスです。基幹システムやERPとのAPI連携に対応し、実績データの受け渡しや予測結果の反映を効率化します。予測値や在庫状況をもとに最適な発注量を自動算出する機能もオプションで提供。専任のデータサイエンティストが、導入前のデータ準備や活用方針の検討から、導入後の精度評価・運用改善まで支援します。
LTV-Zaiko
- ZPM分析で在庫の状態を可視化
- AIによる需要予測で欠品と過剰在庫を同時に防ぐ
- 発注・値引・店舗間移動の提案
株式会社LTV-Xが提供する「LTV-Zaiko」は、受注システムやECカートとの標準連携に対応するクラウド型の需要予測・在庫分析システムです。受注データや商品データを取り込み、商品・SKUごとの消化予測やZPM分析によって在庫状況を可視化します。追加発注や店舗間移動、売価変更の判断も支援。API連携や導入企業向けのカスタマイズにも対応しています。導入後は営業担当とサポート担当による操作方法や分析・施策の支援を受けられます。
α-発注 （株式会社infonerv）
- 需要や仕入れ条件を踏まえて発注リストを自動作成
- 在庫状況をモニタリングし異常を速やかに検知
- AI導入効果の事前検証や定期チューニングなどサポートも充実
Demand Solutions DSX （JFEシステムズ株式会社）
- 4つの計画モジュールをワンシステムで管理可能。
- 業務プロセスに応じ、段階導入や一部モジュール導入が可能。
- Excel計画業務を一本化し、可視化と標準化を実現。
Perswell （株式会社DATAFLUCT）
- データサイエンティストなしで機械学習モデルを活用可能。
- 外部データを取り込み、商品別の予測モデルで精度を向上。
- API連携で発注数や在庫量を自動算出し、最適な発注を実現。
まとめ
需要予測システムの構築では、業務の改善目標を設定し、データや連携要件を整理したうえで、PoCによる検証、本番稼働、運用改善へと進めることが重要です。製品によって、カスタマイズやシステム連携、導入支援の範囲は異なります。自社で対応する作業とベンダーに任せる範囲を明確にし、各製品の機能やサポート内容を比較しましょう。
