基幹業務系システムの開発プロセス（ウォータフォール型による開発を例とする）は，下図のようにＶ字型になります（通常は，開発計画と効果実現は別体系にするのが通常です）。そして，上の部分が利用部門（利用側）が主体になり，下の部分が情報システム部門やベンダ（提供側）が主体になります。
経営の分野：開発計画と効果実現
開発計画とは経営戦略や情報化戦略を経て，個別の情報システムの計画に至るまでの段階です。個々の情報化案件を評価するとき，最も基本的な評価基準は費用対効果です。ところが，効果は情報化だけで実現できるのではなく，業務の改善や改革を通して得られるものですし，それには多くの解決するべき事項があります。その解決は業務部門の責任なのです。
業務の分野：要件定義と外部設計
開発計画までにも，開発するべき情報システムの内容や費用対効果について検討してはいるのですが，具体的に構築するには，さらに詳細について仕様を決定しなければなりません。
それで，業務部門，情報システム部門，ベンダなどからなるプロジェクトチームを編成して，具体的な要求事項を調査して，開発するべき仕様を外部設計書としてまとめ，経営者を含む関係者に提案して，あらためて開発の承認を得るのです。
このフェーズで適切な仕様にならないと，本来の目的とは異なるシステムになって，期待する効果が得られない危険があります。
また，このフェーズがあいまいなままに以降のフェーズに入ると，後になってから大きな手戻りが生じます。これは，開発期間や費用に大きな影響を与えます。特に戦略的なシステムや社外との関係の深いシステムでは，システムへの移行時期（納期）は重要であり，それを延期するのは大きな問題になります。
コード化やマスタファイル
具体的なシステムを構築する分野は、ＩＴ部門やベンダなどの提供側が主体になりますが，業務部門が中心で行うべき作業は多くあります。
例えば，得意先には得意先コードを付ける必要がありますが，コード体系は表示順序や層別など業務での利用勝手に大きな影響を与えますので，業務部門が作成しなければなりません。また，得意先コード，得意先名，住所，得意先区分など得意先台帳に記載されるような項目をマスタファイルが必要になります。これらの整備も業務部門の任務です。
これらが正確に整備されていないと，プログラムは作れませんしテストもできません。
テスト
システムは人間が作るものですから，多様な要因により誤りが生じます。その発見と修正が不十分なままに実施すると大きなトラブルにつながる危険があります。
ところが，要件定義フェーズでなかなか仕様が決まらないとか，それがあいまいなために大きな手直しが発生するなどにより，次第に納期が迫ってくると，テストフェーズにしわよせられ，テスト不十分なままに実施移行することになりがちです☆。
単体テストや結合テストなど，プログラムレベルでのテストは開発者に任せることができます。しかし，システム全体として要求した仕様通りになっているかのテスト（システムテスト）や実際に使ってみてのテスト（運用テスト）は，検収テストであり試運転ですので，発注者である業務部門が主体になって行う必要があります。
運用
システムが出来上がり運用フェーズに入ると，システムにあわせた業務の仕方をすることが重要になります。例えば受注をしたら直ちにコンピュータ入力をすることと定められているのに，まとめて入力するほうが好都合だからといって，数日分を放置しておくと，その間の情報がコンピュータで把握できず，実際とは異なる結果を出してしまいます。新規の得意先が発生したのに放置しておけば，そことの取引データをコンピュータに入力することができません。
手作業の時代では，転記作業が多く非効率でしたが，逆にチェック機能にもなりました。ところがシステム化すると，いったんコンピュータに入ったデータは，なかなか誤りが発見できません。特にリアルタイムのシステムでは，誤ったデータが入力されたとたんに他のシステムへ影響してしまいます。誤ったデータが入らないように，システムにどのようなチェック機能を組み込むべきかは操作者が最も気づくのですから，要件定義のフェーズで提示する必要があります☆。