“今すぐ実務に役立つ”　物流センター運営の教科書　～RFPの作成手順～｜オープンソースの倉庫管理システム(WMS)【インターストック】

「あーる、えふ、ぴぃ・・・？？」なんだか難しそう・・・。と思われるかもしれません。しかし、RFPは全然むずかしくありません。とてもシンプルです。ベンダーに提案して欲しい内容を書面にまとめるだけです。エクセルでもパワポでもＯＫです。「えっ、もっと簡単につくりたい？」もうこの際、メモ帳でも良いでしょう（苦笑）。RFPとして最低限のルールのようなものはあるので、そこさえ外さなければ立派なRFPが仕上がります。

「RFP、なんとなく分かったけど何かメリットあるの？」私に言わせれば、WMS導入する際にRFPを作成することはメリットしかありません。そのシステムが重要であればあるほど、RFPは不可欠となります。またRFPを作成してベンダー側に提出すると、ベンダー側もこのユーザーは本気だな、という気持ちを理解してもらえます。

2.RFPを作成するメリット

RFP作成のポイントは、必ずしも全要件を網羅的に示すことではなく、主要な要件、中でも特異性のある要件を明確にすることです。例えば、WMSでは、ピッキング前の在庫引当のロジックが主要な要件の一つとしてよく挙げられます。在庫引当の際に、入庫日による先入れ先出し(FIFO)の機能が必要な場合に、「入庫日による先入れ先出しの機能が必要」とだけ書くのではなく、得意先によって先入れ先出しの必要有無を設定できるようにするといった、具体的な要件を箇条書きにしていきましょう。商品によっては、シリアル番号を入庫日より優先して先入れ先出しするとか、先入れ先出しは絶対ではなく、警告であり、場合によっては作業者が手動で変更できること、といったように詳細を記していきます。そうすることで、予めベンダー側からそうした機能を想定した提案書や見積書が作成されるので、あとでカスタマイズの追加費用が膨大になって、プロジェクトが頓挫してしまうといったことがなくなります。

このようにイレギュラーな要件を事前に漏れなく正確に伝えることがとても重要です。ここで手を抜いてしまうと、検討違いの提案を受けて、お互い無駄な時間を使ったり、後々、ベンダー側から「そのような要件は伺っていない」といって、機能追加の対応を突っぱねられるようなことにもなりかねません。

3.RFPに盛り込む主な項目

RFPに盛り込む主な項目は以下の通りです。

①プロジェクトの概要

プロジェクトの目的と背景、全体スケジュール、自社のプロジェクト体制、依頼したい提案範囲（スコープ）など、WMS導入における目的やプロジェクトの概要をシンプルに記載しましょう。思いが入り過ぎて、プロジェクトの概要だけで１０ページ以上もあるRFPを見たことがありますが、できるだけ要点を簡潔にまとめた資料の方が、ベンダー側も理解し易いと思います。

②方針と要求事項

システム化の方針や、カスタマイズ方針、保守の方針など記載しましょう。RFPを受けるベンダー側の立場としての私見ですが、方針を示したあとで、具体的な要求事項を記載することをお勧めします。この方針が意外と漏れているRFPが多いですが、プロジェクト全体の方針があるとユーザー企業の考え方がベンダー側も理解できるのでお勧めです。続いて要求事項ですが、要求機能一覧、非機能要件、利用者数、ハードウェア構成・必要数などを記載しましょう。

③提案要領

提案手続き概要、提案日程、締め切り、受付窓口、回答に必要な資料等を明記します。ここでベンダー側に求める回答資料はあまり多くなり過ぎないことが大切です。つい、力が入り過ぎてあれもこれもとベンダー側に提出を求めたい気持ちも分かりますが、ベンダー側も複数の顧客の提案依頼書を受けていますので、必要最低限にした方が回答を受けやすいでしょう。

④別紙資料

ベンダーが提案書を作成する上で、役立ちそうな資料を別紙として準備しましょう。業務フロー（これは必須）、出力帳票等のサンプル、現行システムの概略資料などが一般的です。現行のWMSをリプレイスするような場合は、既存システムの機能一覧や画面のハードコピーなどがあれば、ベンダー側はイメージがしやすいです。

4.RFPでよくある失敗例

RFPについてある程度皆さんの理解が深まったところで、RFPの作成でよくある失敗例を少しご紹介しましょう。最も多い失敗ケースが、機能一覧を列挙して、対応可否を問うやり方です。下図の表のように、求める機能を一覧で列挙して、対応可能かどうかを○×△でチェックするような形です。

多くの場合、ユーザーが列挙する機能はWMSの一般的な機能になるので、実績のあるWMSパッケージなら、これらの基本機能はどこもカバーしています。
そのため、「対応できる」「対応できない」で選択させると、どの機能も「できる」という回答になってしまいます。重要になるのは、パッケージシステムの機能と現場運用のFit&Gapをどれだけ精度高くRFPで確認できるかです。列挙した機能一覧をもう少し掘り下げて、それぞれの現場運用を説明して対応できるかを確認することが大切です。その上で、カスタマイズなしの標準機能で対応できるのか、それともカスタマイズが必要なのか、さらにはカスタマイズの大きさがどの程度の工数かをベンダーもユーザーもお互いに知る必要があります。ただし、詳細設計前のこの段階で、ベンダー側も詳細な工数（何人月）を算出することは難しいので、例えば、カスタマイズに１ヶ月以上必要な場合は「大」というように、「大」「中」「小」程度の基準を設けて、そこから選んでもらう方法をお勧めします。

ベンダーの特徴によって、ユーザーから出てくる機能一覧の受け取り方、理解は違ってきます。例えば、カスタマイズが苦手なASPのようなパッケージベンダーであれば、機能一覧をそのまま自社の標準機能を利用してもらう想定で見積もり算出します。一方でスクラッチやカスタマイズが得意なベンダーであれば、ユーザー企業の規模や業種から、各機能の特異性を予め想定して見積もりに含めることが多いです。後日、コンペに参加した開発ベンダー各社から見積書が上がってきて、機能一覧のFit率は同じでも、費用が全然違うのもこのような理由からです。

こうしたことを知らないと、同じ機能をカバーできて、費用が安いなら安い方のベンダーを選んだ方がいいよね、ということになって誤った選定を行ってしまうことになります。同じWMSであっても、ベンダーの特徴、パッケージ製品の特長は実に様々です。条件を同一にして、同じ土俵で提案を比較できるようにするために、各機能一覧から現場の運用を説明し、特異性のある個所を理解してもらい、必要であればQAの機会を設けて細部について擦り合わせをしておきましょう。