（1）自社の業務や取引先との関係性を洗い出す

RFP作成にあたっては、自社ビジネスの特徴をクリアにした上で、要件を明示しなければなりません。

ひとくちに販売管理といっても、例えば仕入れた商品をそのまま販売する場合もあれば、半完成品に手を加えて販売する場合もあります。部署ごとに扱う商品、仕入先や取引先に特徴がある場合はそのことも記載したほうがよいでしょう。なぜなら、自社としては一般的だと思っていたことでも、ベンダーやシステムの立場からすれば特殊、というケースもあるためです。

（2）システムの全体像を事業と結びつけて示す

要件の取りこぼしをなくすために、どのような事業を営んでいるのかを具体的に示し、その上でシステムの全体像を示すとよいでしょう。例えば製造業なら、取引先とのEDIによる連携、自社の生産管理システムとの連携などが考えられます。
また、複数の事業を営む企業の場合、求めるシステム要件が各事業とどのように紐づいているかをわかるようにしておくことがポイントです。あるパッケージの機能が特定の事業の要件を満たしていても、他の事業の要件は満たせない可能性があるからです。それぞれの事業が求めるものはなるべく詳細に明らかにしておきましょう。

（3）余裕のあるスケジュールを組む

販売管理システムの導入プロジェクトは、会計や人事給与のシステムよりも企業や部署ごとに特色があり複雑なだけに、より長い期間を要します。認識をすり合わせるために、ベンダーの立場としてはRFPの精査や質疑のやり取りに時間をかけたいので、RFPの回答期限に余裕を持たせておくとよいでしょう。

その他にも、システムの要件定義や設定、カスタマイズ、システム導入そのものにも時間がかかります。販売管理システムにおいては、エンドユーザーの数や使用する機能が多いことから、トレーニング期間も視野に入れてスケジュールを組むべきです。

（4）コアコンピタンスを明確にしてカスタマイズの範囲を決める

会計や人事給与システムと比べて、販売管理システムはパッケージ標準導入が難しいシステムです。そのため、実務と多少手順が異なっても標準機能に合わせるべき業務と、カスタマイズしてでも実現すべき機能の判断基準を明確にします。

例えば、社内業務しか関連しない要件であれば、これまでの進め方と違っても標準機能に合わせます。しかし、重要な得意先との接点に関連する要件が標準機能と合致しない場合はカスタマイズすべきでしょう。

判断基準を設ける際は、自社のコアコンピタンスを明確にするとよいです。例えば、卸売業で「即納できることが顧客から評価されている」のであれば、即納に必要な要件については、カスタマイズしてでも実現しなければならないでしょう。

（5）社内でコンセンサスを取る

スクラッチ開発は、改修を繰り返すことでかゆいところに手が届く仕様になっています。そうしたシステムを長年運用してきた場合は、社員も既存システムの扱いに慣れています。それゆえに、できるだけ標準機能を使用することを前提に、スクラッチからパッケージへ刷新する場合はユーザビリティが低下してしまう可能性があるため、あらかじめ社内の合意形成を図ることが重要になります。

システム担当者はコンセンサスを取って進めているつもりでも、実際には現場担当者と合意形成ができておらず、後に混乱をきたすケースもあります。スクラッチからパッケージへ移行するような大きい変化が生じる場合は、業務が大きく変わることをトップが明確に表明するとよいでしょう。