RFP に抜けがないか、20項目で確かめる

ここが曖昧だと、以降のすべての判断に軸がなくなります。

• リプレイスの目的を、一文で書けている 「保守期限だから」で止まらず、何を良くしたいのかまで。
• 保守期限以外の理由を、業務の言葉で説明できる 期限だけが理由だと、現行踏襲の提案しか集まりません。

ここが書けていないと、ベンダーは接続の手間を見積れません。

• 部門システム（検査・画像・調剤・給食など）の一覧がある 電子カルテ本体だけでは足りません。
• システム間の接続関係が、図か表になっている どこからどこへ、何のデータが流れているか。
• 外部接続を洗い出せている オンライン資格確認・地域連携・レセプト・保守回線など。

機能名で書くと製品名に引きずられ、実現方法を縛ってしまいます。

• 要件を「主語と場面」を伴って書いている ×「予約機能があること」／○「外来の看護師が、診察中にその場で次回予約を登録できること」
• 現場ヒアリングを「今の不満」から集めた 機能要望から入ると、現行システムの延長しか出てきません。
• 要件に優先順位を付けている 必須／望ましい／不要。全部必須にすると価格が跳ねます。

「速いこと」「安全なこと」では要件になりません。数字か、判断できる条件で書きます。

• 性能を数字で書いた 画面の応答時間・同時に使う端末数・ピーク時間帯（外来受付の朝など）。
• 可用性を数字で書いた 止まってよい時間・計画停止の頻度・障害時の復旧目標。
• セキュリティ要件を具体的に書いた 認証方式・アクセス権限の設計・アクセス記録の保存期間。
• バックアップは「復元テストを誰がいつ行うか」まで書いた 取得しているだけで、戻せることを確認していない例が少なくありません。

リプレイスで最も揉める部分です。「現行データを移行のこと」だけでは範囲の解釈が割れます。

• 移行対象の期間（何年分か）を決めた 全期間か、直近◯年か。ここで費用が大きく変わります。
• 種別ごとに移行可否と方法を分けて書いた 構造化データ／文書／画像は、それぞれ難易度が違います。
• 移行後の検証方法を書いた 誰が、何を、どう確認したら「移行できた」と言えるのか。

書かないと、稼働後に「それは保守範囲外です」が始まります。

• 問い合わせ窓口の時間帯と、時間外の扱いを書いた 夜間・休日に誰が出るのか。
• 障害時の駆けつけ条件と復旧目標を書いた 何時間以内に、どこまで戻すのか。
• リモート保守の接続方式と、バージョンアップの費用負担を書いた 外部から院内へ入る経路は、それ自体が安全管理上の論点です。

様式が揃っていないと、比較に膨大な手間がかかります。

• 全社に同じ様式で提案を出すよう指定した 項目の並びが揃うだけで、比較の手間が桁違いに減ります。
• 評価軸を事前に示した 価格・機能適合・移行実績・保守体制など。示すと提案の質が上がります。