RFP(Request for Proposal)(2)

以前、RFPについて少し述べたかと思います。その時は「提案依頼書」と訳していたのですが「要求仕様書」とも言われているのでまず追加訂正させていただきます。性格には「Request for Proposal＝提案の依頼」ですから前述で間違っていないのですがまだまだ日本ではなじみが薄い言葉のようです。

この要求仕様書（提案依頼書）、小さなシステムだとほとんど不要です。A4用紙で１～２枚実現したいことを記述するとほとんどOKの場合があります。しかしシステムというのは規模に応じて複雑さが増す傾向にあるため、部門にまたがるような情報システムを構築する場合は非常にデリケートな取り扱いが必要です。ちょっと図A～Cを見てください。

図Aは単純な情報システムを意味しています。１部門しか情報化していないため情報もその部門しか使っていません。図Bは中規模な情報システムです。多数の部門で情報を共有するために作業指示や参照する情報を示す線が複数になってきています。図Cではそれを一元管理しようと情報を一つにまとめました。理想に近いと思われますが、その分間違いや修正があったときに他部門に影響が発生します。

部門AとかCではピンとこない方もおられるかもしれませんので、もう少し具体的に書いてみましょう。例えば経営部門は経営計画を作成・指示し、それが計画通りに遂行されているかをチェックする義務があります。販売を管理する部門は営業・見積り作成・受注・在庫確認・納品・請求・入金等を管理しなければなりません。生産部門は生産スケジュールに従って人員と材料・外注を管理します。在庫管理部門は、入荷出荷や在庫引当、棚卸、発送等を管理します。財務部門は手形や現金・売掛金や買掛金の処理、資金計画のチェック等を管理します。運送部門が独立している場合もありますし、商品開発部門や広報部門のウェートが大きい企業もあるでしょう。それはあなたの企業のモデルによって違います。でも、突き詰めて言うとこのモデルはそんなに種類がありません。そして、情報の種類というものも実はそんなに種類はありません。ただ、同じ意味の情報を違う言い方や違う形で保存していたり、違う情報を同じものとして扱おうとして事態を複雑にしているのです。

もっと単純にしていくと、「顧客情報」というものがあるとします。名前ひとつとっても姓名を一つと捉えるか姓と名を分けて扱うか、生年月日を西暦で扱うか和暦で扱うかが部門毎に違っていたらとても面倒ですよね？売上データも経営者の方は毎日でも確認したいのに、ある１部門だけは一月遅れになったらなんにもなりません。そんなことの積み重ねが「さっぱりわからない」「ちっとも活用できない」につながるのです。

ですので、我々の仕事はまず「現状」を把握することから始まります。そして現状と「あるべき（理想の）姿」のギャップを調べ上げていきます。売上向上やコストダウンの妨げがその中に必ず潜んでいます。その「妨げ」を解決していくための資料、それが要求仕様書というものになって明確にされていくわけです。

昔から言う「段取り八部」の段取りに相当すると考えられています。経営者の方々は、ぜひそのことを念頭において業務改善に向かって欲しいと思います。