需要予測の要件定義を考える：SCMコンサルティングの現場から（2）（1/2 ページ）

[南野洋一，＠IT]

＜今回の内容＞

• システムの構成と必要な情報
• 需要予想システム要件定義の概要
• 需要予測のモデル調整
• 履歴データの取り込み
• 予測プロセスの策定

　前回「何のための需要予測システムか？」では、需要予測の概要について述べました。今回は前回の次のステップとして、SCMの中の需要予測を行うに当たって、どのようなことを要件定義としてまとめていけばよいか考えてみましょう。また後半には、作成した予測のモデルの調整についても記載しました。

システムの構成と必要な情報

　需要予測システムは、どのような情報を基に構成になっているのでしょうか？ 大まかには次のようなものから成り立っています。詳細は図1をご覧ください。

インプット情報

　インプット情報としては、次の3種の情報を用意します。

• 商品情報
• 営業情報
• 出荷（販売）情報

アウトプット情報

　次にインプット情報を基に需要予測システムがアウトプットする情報があります。

• 需要予測結果

予測結果の修正

　アウトプット情報として出力された結果に対する検証と修正が必要です。

• 予測値の修正
• 予測精度の分析

図1　需要予測システムの処理の流れ

需要予想システム要件定義の概要

目的

　需要予測システム導入の目的を明確にしておく必要があります。例えば、次のようにきちんと言い切れるようにしておくとよいでしょう。

販売するすべての商品を対象にし、出荷履歴を使用して、週次のサイクルで統計的モデルによって需要予測を算出したものに、営業情報、商品情報を追加した需要計画を作成し、在庫補充計画、基準生産計画にワンナンバーで連携する。

　もちろん、必ずしも「販売するすべての商品を対象」にすることはありません。場合によってはピックアップされた商品だけを対象にすることもあるでしょう。インプットデータは、「出荷履歴」ばかりではなく、「販売履歴」の場合もあるでしょうし、「週次のサイクル」ではなく、月次や隔週のサイクルも考えられます。

　「統計的モデルによって需要予測を算出」が各需要予測ソフトのエンジン部分になります。この処理された需要予測の結果を基に、営業情報、商品情報などの各種イベント情報を加味して、「需要計画」を作成していきます。

　最後の「在庫補充計画、基準生産計画にワンナンバーで連携する」の部分は、システムによっては、需要予測のみを行う場合もあるはずです。この場合はほかのシステムとの連携はなくなります。つまり、需要予測の結果は、今後の生産計画を策定するための参考資料となるアウトプット（帳票形式など）が出力され、実行系システムとのデータ連携はありません。

組織単位

・システムの運用

　システムそのものは、SCM部門の「需要予測担当者」「需要予測管理者」によって運用されます。「担当者」というのは、主に需要予測計画を作成する人物、「管理者」はマスタ情報の管理や基幹システムとの連携などを行う人物です。

・関連する組織との連携

　「担当者」「管理者」以外にも、“需要”に関係する情報を扱う部門の協力が必要です。例えば、プロモーション活動を行うマーケティング部門や販促活動を行う営業部門と情報を共有し、需要予測に反映させます。

アウトプット

・需要予測計画書

　システムからアウトプットされた情報は「需要予測計画書」の形にまとめられます。場合によっては、汎用の資料から自社独自のグラフや表への変換作業を、Excelなどを用いて行うこともあります。

対象品

・継続して需要のある製品

　需要予測を行うには本来、対象となる製品に過去の実績があることが必要です。過去2年間以前に発生した製品で、継続して需要のあることが望ましいでしょう。この“2年”というのは、前回も指摘したとおり、季節性などを勘案し過去の履歴として2年間分ぐらいのデータがないと、正確な結果が導き出されにくいことに起因しています。

・新製品、リニューアル（モデルチェンジ）品

　新製品やリニューアル品は過去の生産（販売）履歴がありません。そのときは参考となるデータに基づき作成を行います。例えば、ブラックの缶コーヒーをリニューアルした場合は、参考として、リニューアル前に販売して製品の生産履歴のデータを基に需要予測を行い、その結果を基にデータの確度を上げていくことを指します。

・対象外品

　あまりないと思いますが、対象外としては、例えば見本品や試験品そして自社で生産を行っていない仕入れ商品などが該当すると考えられます。後者については、需要予測結果を工場の生産計画と連携させている場合は、必要ないと考えられるからです。

　しかし、化学メーカーなどでは原材料を自社で生産し、製品の生産は委託先の協力工場で原材料を用いて生産を行い、その生産物を購入するといった生産形態をとることがあります。こうした場合は、原材料の生産計画を策定するために需要予測の対象製品とする必要があります。

a化学品メーカー 　 委託先b工場 　 a化学品メーカー 生産の流れ 原材料の生産 （原料Aを生産） 製品の生産 （原料Aから製品Bを生産） 顧客へ販売 （製品Bを販売） 予測の流れ 製品Bの生産数から、原料Aの生産数を決定 予測に基づき、Bを生産 製品Bの需要予測を実施

図2　委託生産の場合の需要予測の例

需要予測のモデル調整

　導入目的、アウトプットの内容や形、何を需要予測の対象品として扱うのかといった要件を決めたら、次に、需要予測をより精度の高いものとするために、予測モデルの調整を行います。

　調整作業は1回で終わるものではありません。製品の販売状況は、さまざまな要因で計画と実績が乖離してきます。そのため需要予測も当初の設定どおりにいかなくなってきます。そのため、販売状況にあわせて“予測モデルの調整”を行っていきます。月ごとなど定期的・継続的に調整をローリングして行っていくことにより、予測精度の高いモデルが作られていきます。以下に調整する際に検討する項目を挙げます。

商品情報

　まずは商品そのものの情報です。商品特性は、市場の反応、ブランド力などによって予測も変わってきます。

・季節性の有無

　シーズンを通じて販売される商品か、季節限定の商品かといった情報。限定というのは例えば、冬のみ販売される缶入りのコーンスープやお汁粉などです。

・マスコミ情報の影響

　テレビの情報番組などで、「ココアが体に良い」「ヨーグルトが花粉症にきく」といった情報が報じられた場合、これをシステムに加味していきます。ただし現実的には、生産するための原材料の在庫や生産計画が2カ月ぐらい先まで決定している場合もあり、急な増産は対応しづらいかもしれません。

・イベント、マーケティングキャンペーンの影響

　自社や販社がその商品に対して、何らかのキャンペーンを行えば、需要に影響があると考えられます。例としては、CMなどの影響が挙げられます。

・製品ライフサイクルの長短

　製品ライフサイクルとは、商品が市場に投入され、成長・成熟・衰退する過程をサイクルとしてとらえるものです。製品の耐用年数、商品に対する消費者の飽き、新製品の登場による旧製品化など、複合的な要因で製品ライフサイクルは長短さまざまです。製品寿命の長い例では、“リポビタンD”のようなロングセラー商品があります。対照的に、季節ごとに新製品が登場するパソコンはライフサイクルが短い例の代表製品です。

　製品ライフサイクルが短く、需要そのものが大きな“ブーム”や“流行”の際の、需要予測は難しくなります。もうかなり以前になりますが、“たまごっち”という携帯ゲームが大きなブームになった時期がありました。当初、品不足が発生したため、メーカーは急遽増産を行いましたが、最終的には大きな在庫を残してしまったという例もあります。

・商品情報源

　これらの情報の出所は、営業部門を中心とした関係部署が多いと思いますが、企画部門や宣伝部門などにも重要な情報があるでしょう。

営業情報

　営業・販売に関する情報です。

・キャンペーン、特売情報

　スーパーマーケットなどの特売情報です。品扱いとなれば、需要が増えることが予想されます。

・新規採用情報、チャネル情報

　どの販売チャネルで、どれだけ取り扱われるかといったことは、当然重要な要素になります。コンビニエンスストア・チェーンに、取扱商品として新たに採用されると売り上げはぐんと伸びるはずです。同様に日本の商慣習では問屋（商社）の位置付けも大きなものです。そこでの採用も、販売ルートの拡大につながり需要を押し上げることになります。システムへの入力は、パラメータの設定で需要の平均値を上げることにより対応を行います。

・競合情報

　オンリーワンの商品でなければ、競合する商品があるはずです。これらの情報を入力します。消費者の信頼を失うような不祥事が発生すると、業界内で競合他社の需要が上がります。

・営業情報源

　販売情報システムや販売会議などの情報を基に調整を重ねていきます。

・イベント情報

　需要予測システムが算出した需要予測パターンとは異なる将来の営業情報を収集し、イベントとして予測値に反映します。

・作業プロセス

　販売イベント、キャンペーン情報を基に需要予測システムから算出された予測値に対して追加の情報を反映させます。

予測精度の分析結果

　需要予測のシステムによっては、グラフで“外れ値”などを示すものがあります。あるラインを設定し、外れ値の修正を行うことで確度を上げていきます。

　例えば、ある製品の予測を行う場合を考えてみます。今月はまだ月初めで、今月以降の予測を行うのであれば、今月はまだ実績が出てきませんから、先月までの出荷データが需要予測システムにインプットされた状態です（先月までが実績データで、今月以降が予測データとなります）。

　需要予測システムは、あるアルゴリズムによって過去の実績により予測を行います。この例では、先月までは実績データです。言い換えると需要予測システムはその製品の販売（出荷）モデルを自動生成しているともいえます。

　さて、需要予測を行った結果、従来のモデルの平均値から外れ、大きく超えるエラーが発生したと警告が上がったとしましょう。その外れた値が“正”の位置にあれば何らかの販売促進活動を行って実績が伸びたなどのことが考えられます。また、逆に“負”の位置にあれば、先月に競合他社が販売促進活動を行ったり、新製品を投入したりしていたのかもしれません。

　システムでは、実績データを基に予測データを生成していきます。入力された以外の“イベント”は、結果に反映されません。その点を、人間系で追加・修正することが必要となります。この例の場合、イベント情報が欠落しているほか、システムのパラメータの1つである“平均値”の修正が必要ということも考えられます。

---

　上記の各情報をどこから、どれだけ収集するかのガイドラインを作る必要があります。単に製品の集荷履歴からの需要予測だけでは良い結果は得られません。