これらのドキュメントは、基本的にはシステム開発を受諾したシステムベンダー側が作成します。私がこれまで携わってきた多くのプロジェクトはパッケージを中心とし、スクラッチ開発によってパッケージシステム周辺に限定的な機能を有したシステムを補完していくというものでした。そのため、プロジェクト内で作成するドキュメントは、パッケージベンダー固有のフォーマットによるドキュメント（主にシステム機能フローとカスタマイズ設計書）とシステム開発ベンダーが一般的に作成するドキュメント（システム基本設計書）の両方がありました。

ここでポイントとなるのは、「システム機能フロー」の位置づけとその中身についてです。前出のクライアントとのやり取りの中で、「システム機能フロー」について説明しているセリフがありますが、このドキュメントに対するシステムベンダーの認識とクライアントの認識にかい離があるということが頻繁に起こります。システムベンダーは、プロジェクトが対象とする業務を一定レベルで理解しています（そもそも理解していることが受注の条件となるため）が、同業務を実務としてこなしているクライアントと比べると、詳細レベルまでは理解できていないことが一般的です。
また、システムベンダーはシステム側の目線で業務を見るため、どうしても実業務についての理解度や実務感覚という点で、クライアントと比較すると低いものになってしまいます。これらの結果、システムベンダーが記述する「システム機能フロー」はその名のとおり、「システム」が対象とする業務に対して提供する「機能」を業務の「流れ（フロー）」に沿って記述したものになります。一方のクライアント側にとってシステム開発の対象業務は業務そのもののため、システムが対象とする業務とシステム対象外の業務も包括的に記述した、新システム導入後の「業務プロセスフロー」を必要としています。つまり、システムの機能を中心としたドキュメントではなく、「業務」を中心としたドキュメントを必要としています。
そしてシステムベンダーは、システム開発のプロとして、システム機能を中心としたドキュメントを作成しますが、必ずしも対象業務の業務の専門家ではないため、業務を中心としたドキュメントの作成には役不足といった面があります。

私自身10年以上物流センターへのパッケージ導入やシステム開発に携わっており、倉庫業務運営を支援する仕事もしてきましたが、やはり業務プロセスを書くときの目線はシステム中心となってしまい、業務の専門家から見ると抜け漏れだらけだったりするようです。私の経験上、上記のようなギャップに対してクライアントと共に具体的な対策を打つことなく進めてしまったプロジェクトで、その後直面することになった課題は以下のようなものでした。