RFPの業務要求を実際に表現するアウトプットには，以下のようなものがある。
［必須のもの］
・現行システム概念図
・現行業務フロー（現行システムがない新規の場合は手作業フロー）
・現行業務概要
・業務基本要求（現在当たり前にできている基本機能）
・ユーザー要望（現行システムへの要望）
・データ情報
・現行システムの入出力物（特に帳票類）
［あると良いもの］
・新業務フロー
・特徴的な処理の説明図
・現行システムの画面
・新システムの画面イメージ
上記に挙げたものの中から，今回は業務フローについて説明しよう。RFPで必須の業務フローは，現行業務フローである。現在業務がどのように行われ，システムがどのように業務に関わっているのか，をできる限り正確にベンダーに伝える必要がある。現行システムを担当しているベンダーはそれを熟知しているはずだが，競合となる他の新規ベンダーは当然ことながら知らない。したがって，それらを正確に伝える必要がある。
では，現行業務フローはどのように作成すればよいか。ポイントは「パターン化してまとめる」ことである。まず，業務フローをあまり細かく分けるのは考えものだ。小さな分岐までを別々の処理として捉え，そのすべてを別の紙に業務フローとして書いてしまうと，枚数が極端に増えてしまい，作成負荷が著しく増大する。
さらに，ベンダーもRFPの段階ではあまり細かい情報までは咀嚼（そしゃく）しきれないことが多く，かえって混乱したり，あるいはシステム規模を過大にとらえてしまったりと弊害もある。「詳細よりも網羅性」を意識して，「新規登録処理」「入金処理」といった業務パターンに分割して整理できれば，そのパターン化した業務を使ってフローを作成するのがよいだろう。
また，新業務フローがなぜ必須ではないのかと疑問に感じるかもしれない。RFP作成の段階で，新しくやりたいことが決まっていて，業務フローに落とせるほど具体化していれば，もちろん，新業務フローを提示すべきであるし，提示するメリットは大きい。しかし実際には，この段階では具体的なフローまでは決まっていないことが多い。新業務フローをRFPに載せようと，詳細が詰め切れていないのに無理して中途半端なフロー図を作成することはやめるべきである。間違った情報をベンダーに与えてしまい，後々のもめ事の原因となる可能性があるからだ。
RFPの長所であり逆に怖いところでもあるが，「RFPにこう書いてあった」というのは証拠としてずっと先まで残るのである。また，業務パッケージ・ソフトの利用を前提に検討している場合などは，詳細な新業務フローをいくら書いても，あまり意味がない。「パッケージでこの新業務フローの通りに寸分たがわずやれと言われてもできません」とベンダーが逃げてしまうこともある。新業務の詳細がはっきりしていない場合やパッケージを利用する場合は，要件定義の段階でベンダーのSEと一緒に新業務フローを作成すると割り切ってしまった方がよいだろう。
発注者ビューガイドラインのルールがおすすめ
業務フローの書き方は，ベンダーやSE個人によって流儀がいろいろとあるようだ。しかし，ユーザーからすれば，そうした「会社流儀」「個人流儀」はあまり歓迎すべきことではない。特に業務フローは情報システム部門だけでなく，エンドユーザーもかかわるべきアウトプットである。例えば，SE視点でデータベースが主役のように書かれている業務フローは，エンドユーザーからすれば「よく分からない難しい資料」になってしまう。そういう先入観を持たれると，せっかくの業務フローにきちんと目を通してもらえないといった事態を招く。
おすすめは，IPA（情報処理推進機構）が公開している「発注者ビューガイドライン」の「システム化業務フロー」のルールに則って作成することである（図4）。これはその名の通り，発注者（エンドユーザー）の視点からの業務フローの書き方になっているので，エンドユーザーにも分かりやすい。
本来業務フローは，情報システム部門ではなくエンドユーザーに書いてもらうのが理想であり，このルールであれば書くことができるというエンドユーザーも多くいる。実は筆者も，以前は個人流儀で業務フローを作成していたが，ある案件で顧客から「なぜIPAがこのようなガイドラインを出しているのに，使わないのか」と質問され，返答に詰まった経験がある。顧客に教わることも多いのである。
