Manufacturing Cloud 導入初期、私が販売予測で犯した設計ミスとその顛末

日付:
Manufacturing Cloudのプロジェクトで、特に販売予測（Account Forecasting）周りの設計判断には、今でも苦い思い出がある。これは、私がSalesforceコンサルタントとして、顧客の真のニーズを深掘りしきれず、標準機能への固執が招いた失敗だった。

A. manufacturing cloud で実際にやらかした判断

当時の顧客は、複雑な組立製品を扱う中堅製造業だった。彼らは長年、Excelで非常に詳細な販売予測を管理しており、月次で製品SKUレベル、顧客アカウントレベルでの需給調整を頻繁に行っていた。特に、季節変動や原材料の入手状況に合わせた週次での数量調整が必須だった。

私はその時、Manufacturing CloudのAccount Forecasting機能こそが、彼らの課題を解決する「銀の弾丸」だと信じていた。Sales Agreementで確定した契約数量を基盤に、Account Forecastingが自動的に集計・表示されるというコンセプトは、システムとして非常に洗練されているように見えたからだ。「標準機能を最大限に活用し、カスタマイズを最小限に抑えるべき」という当時の私のコンサルティング原則にも合致していた。

私は顧客に、Sales Agreementで計画的な販売数量を設定し、そこからAccount Forecastingが生成される仕組みを説明し、強く推奨した。彼らのExcelでの複雑な計算ロジックも、Sales AgreementのカスタムフィールドやCalculation Factorを組み合わせれば何とかなるだろうと、楽観的に考えていた節がある。Forecast Quantityの手動調整機能についても、多少の修正であればこれで対応できると説明した。

後から「やらなければよかった」と思った設計

結果として、この設計は現場でほとんど使われなかった。顧客が求めていたのは、確定した契約数量の集計ではなく、市場の変動に対応する「生きた需要予測」の入力と調整のしやすさだったのだ。

Sales Agreementは、ある意味「コミットメント」に近い性質を持つ。しかし、顧客の現場担当者が日次・週次で頻繁に更新したいのは、もっと流動的な「見込み」や「可能性」の数量だった。彼らはExcelであれば、ドラッグ＆ドロップや数式のコピペで、膨大な数の製品ラインや期間の数字を一瞬で調整できていた。Salesforceの標準のAccount Forecastingでは、Forecast Quantityを個別にクリックして編集する操作が、彼らの業務スピードと乖離していたのだ。

Sales Agreement自体も、彼らの販売プロセスにおいて、そこまで「契約の中心」ではなかった。むしろ、見積もりや受注、そしてその後の生産計画に影響を与えるための「予測数値」こそが重要だった。私はSales Agreementを中心に据えることで、予測プロセス全体を整合させようとしたが、現場はその「整合性」よりも「柔軟性」と「操作性」を求めていたのだ。

結局、現場の営業担当者はSalesforceでSales AgreementやAccount Forecastingを更新する手間を嫌い、結局Excelで予測管理を継続してしまった。Salesforceに残るのは、最新とは言えない予測データだけ。私は「なぜ現場はシステムを使ってくれないのか」と頭を抱えたが、原因は初期の私の設計判断にあった。

当時検討したが、選ばなかった選択肢とその理由

当時、カスタムオブジェクトでより柔軟な予測管理の仕組みを構築することも検討した。しかし、その場合、Sales AgreementやOpportunityとの連携、レポート構築、さらにはSalesforceの標準的な集計機能（ロールアップサマリーフィールドなど）との整合性をどう取るか、という点で複雑さが増すと判断した。

また、外部のBIツールやExcel連携ツールを導入して、Salesforceのデータを柔軟に分析・更新する選択肢も頭にはあった。だが、プロジェクトの予算と期間の制約、そして「Salesforce内で完結させたい」という顧客の要望（これも私が引き出したものだったが、真意を汲み取れていなかった）もあり、標準機能での解決を優先した。

今なら別の選択をする

今なら、まず顧客の「予測」という言葉の定義を徹底的に深掘りする。それは確定に近いものか、それとも変動の激しい需要の「見込み」なのか。そして、その予測がどの程度の粒度（日次・週次・月次）で、誰が、どれくらいの頻度で更新するのかを、より具体的にヒアリングするだろう。

もし、当時と同じように「Excelでの週次・SKUレベルでの大量データ更新」という要件が出てきたら、標準のSales AgreementやAccount Forecastingをそのまま使うのではなく、以下のいずれかのアプローチを提案しただろう。

  • カスタムオブジェクトとグリッド形式のUIの導入:

    Salesforce LabsのAppExchange製品や、カスタムコンポーネント（LWC）で、Excelライクなグリッド形式の入力画面を開発し、予測データを管理する。これにより、現場の操作性を維持しつつ、Salesforce内でデータの一元管理を目指す。データモデルとしては、特定の期間と製品、顧客の組み合わせで予測値を保持するカスタムオブジェクトを用意する。

    // 仮のLWC実装の一部 (今ならこうは書かないかもしれないが、当時の検討イメージ)
// これはあくまでUIのイメージであり、データ保存ロジックは別途必要
<template>
    <lightning-datatable
        key-field="id"
        data={forecastData}
        columns={columns}
        oncellchange={handleCellChange}
        draft-values={draftValues}>
    </lightning-datatable>
    <lightning-button label="Save Forecast" onclick={saveForecast}></lightning-button>
</template>

    このアプローチは、初期開発コストはかかるものの、長期的な操作性とデータ活用を考えると、結果的にROIが高くなる可能性があった。

  • データローダーや外部連携ツールとの組み合わせ:

    Excelでの入力自体を否定せず、定期的にデータローダーや統合ツール（MuleSoftなど）を使ってSalesforceに取り込む運用を設計する。あるいは、Salesforce Connectなどで外部の予測システムと連携し、Salesforceはあくまで実績データや契約情報を管理するハブとする。

  • 業務プロセスの簡素化提案:

    顧客の業務プロセス自体に「本当に週次でSKUレベルの調整が必要か」「その作業負荷に見合う効果があるのか」という問いを投げかけ、場合によっては予測の粒度や頻度を見直すよう強く提案する。コンサルタントとして、現状維持の要件をただシステムに落とし込むだけでなく、あるべき姿を提言する役割を果たすべきだった。

標準機能の活用は重要だが、それが顧客のコア業務のボトルネックになるなら本末転倒だ。標準機能の制約を正確に理解し、それが顧客の求める「価値」と合致するかどうかを、より深く見極めるべきだったと、今では強く反省している。

これは当時の自分向けのメモだ。

コメント

コメントを投稿