提案する側、される側

本日、ある提案依頼書（RFP:[Request For Proposal]）を元に提案書を作成するという研修を受講しました。丸1日掛かりとは言え、全てを網羅した提案書を仕上げることはやはり時間的に難しく、半熟状態。いやはや。。。

提案書を作り上げる（提案依頼書を読み込み、最善の案を提示する）ことも大変ですが、提案を求める（経営戦略を成功に導くための最善な案を求める）側も楽ではありません。

過去にこのブログでも経営戦略の策定から戦略情報化企画、情報化資源調達、 情報システム開発・テスト・導入、運用デリバリー・・・と説明してきましたが、この提案依頼書の出来がプアであれば、求める改革案が手に入りません。IT戦略の失敗、ひいては経営戦略の失敗に繋がりかねません。少々大袈裟でしょうか。。。

ITコーディネータ協会では、情報化資源調達フェーズ、情報システム開発・テスト・導入フェーズ、 運用サービス・デリバリーフェーズで作成する、提案依頼書（RFP:[Request For Proposal]）、および、サービス品質保証（SLA[Service Level Agreement]）の見本を開発し、提供しています。

●「RFPとSLAドキュメント見本提供（ITコーディネータ協会）」はこちら●

架空の企業（金属加工卸業）を設定し、開発委託用のRFPとSLA、および運用委託用のRFPとSLAの4分冊で構成されています。今後の参考に一度、ご覧下さい。PDF形式で提供されています。（ITコーディネータ協会会員にはWORD形式で提供されます）

ポテンヒットでサヨナラゲーム

ここ最近の天候は猫の目のように変わります。冬物をクリーニングに出せずにいますし、体調管理も大変です。皆さんもお体にはお気を付け下さい。

さて、現在、基幹システムの全面刷新を目指す提案依頼書（RFP:[Request For Proposal]）への対応で私自身、バタバタしております。RFPの作成側も大変ですが、読み込む側も大変です。RFP作成側（要求側）は最善の提案を求め、ベンダー側は競合を排除し選定されるべく必死です。

しかし、このRFPには全ての事項が明記されている訳ではありません。もちろん、ベンダー側は機能や費用、スケジュール、サービス方針等に影響を与えかねない事項は明確にした上で提案する必要があるため、事前に定められた質問方式に則り確認しますが、それでもグレーな部分が出てきます。（RFP提示時点で詳細設計レベルまで落とせないですよね。落としたとしたら、本来提案して貰いたい自社の潜在的な部分が手に入りませんし。）

そのため、プロジェクトにはリスクが付き物です。事前にリスクを回避すべく事項を洗い出し、スケジュールや費用面に於いても、双方の見解を明確にし、SLA[Service Level Agreement]（サービス品質保証）を固めなければなりません。提案書に記載される前提条件はベンダーの自己防衛、RFP作成側（要求側）はこの解釈を怠ってはいけません。

そのため、グレーな部分をシロ・クロはっきりさせなければなりませんが、必ずしも「金を払う側」が主導権を取り、「ベンダーが泣く」のではありません。提案・見積の甘さに起因するのか、双方ともに想定できなかったことかを協議しなければなりません。スケジュール面は調整が必要ですが、費用面では双方が見え形で共有する「プロジェクトリスク費」を設け、運営することも検討要です。

それにしても日本語は曖昧ですね。色んな解釈ができます。アナログとデジタルをどう使い分けるかで、その人のセンスが問われるのかも知れません。。。