現状分析段階におけるAs-Is業務プロセスの可視化によって、他部門の業務内容が見え、同じような作業を複数の部門で重複して実施していることや、同じような問題で悩んでいたことなどを認識することができる。また、部門としてではなく、企業全体としての観点から解決しなければならない問題もみえはじめるようになる。
これらの事象・問題から企業戦略に照らして課題として抽出し、部門を超えた全社的な観点から改善の方向性を整理していく。
システム化要件との関係では、システム化の対象領域や要件の抽出に漏れが出にくくなり、構築フェーズでプロジェクトが手戻りするリスクを軽減できる。

設計段階におけるTo-Be業務プロセスの可視化は、現状分析で抽出された改善の方向性を念頭に置き、現行の業務プロセスをあるべき業務プロセスとして描き直していく。
この新しい業務プロセスに、課題を解決する業務処理手順が明確に定義し直されることによって、改善された業務プロセスを支援する情報システム要件が明確になっていく。
具体的には、何のためにシステム化をするのか、すなわち対象となる業務プロセスを支援する目的と、入出力がある場合はそのイメージ/処理方式を概要レベルでまとめる。
この情報システムの外部仕様書はユーザーにとってはどんなシステムが出来てくるのか、開発側にとっては何を作ればよいのかが分かる、両者を橋渡しする唯一のドキュメントになる。

市販のERPパッケージを導入する場合には、パッケージが想定している業務プロセスも考慮しながらTo-Be業務プロセスを作成する。
To-Be業務プロセスをシナリオにして、フィット・ギャップ分析をすることで、パッケージの基本的なセットアップ情報(マスタ・コード設計、各種パラメータ設定)の方針や、洗い 出されたギャップに対して業務処理手順を見なおすのか、アドオン開発要件としてあげるの かを検討していく。