小規模なシステム以外では、システム開発をベンダに請負契約で発注するのが一般的ですので、それを前提としたシステム調達の手順を概観します。
- 基本方針の決定
- 経営戦略やＩＴ戦略から、開発するべき個別システムが実現すべき機能が与えられます。しかし、ＩＴ戦略からブレークダウンした段階では、未だ具体的な内容になっていないのが通常です。また、対象業務を担当する利用部門では日常的な課題の解決を望んでいますし、将来の対策を考えています。それに、情報システムは実際に使われて効果が得られるのですから、使いやすいものでなければなりません。このような利用部門からの要求機能も実現しなければなりません。このような要求を整理して、構築すべきシステムの基本方針を作成します。
- ＲＦＰの作成
- 情報システムを設計するには、基本方針だけでは、あまりにも雑すぎます。何をしたいのかをＩＴベンダにも分かるように、より具体的に詰める必要があります。組織図や業務の流れ、想定されるデータの量、現在のシステムなど、システム構築に必要とされる多様な資料を整理する必要があります。それらを、ＲＦＰ（Request For Proposal：提案依頼書）として整理して、複数のベンダに提案をしてもらいます。その提案書を比較検討して数社の候補に絞り、ヒアリングなどをして一社に仮決定します。
- 要件分析・外部設計、契約
- ＲＦＰが完全なものであり、提案書が完全にそれをカバーしているならば、提案書そのものがシステム仕様書（業務の観点から記述した仕様なので「外部設計書」ともいう）となりますが、そのようなことは稀です。さらに説明やヒアリングを行い、再度提案してもらうこともあります。
そして、複数の提案のなかから、最も適切な提案をしたベンダと契約をします（どの工程までの契約にするかはいくつかあります）。
契約をしたベンダとさらに詳細な検討を重ねて、ベンダは、この段階で実際の利用者へのヒアリングなどを行い、最終的なシステム仕様書を作成し、発注者とベンダの業務分担、納期や費用などの合意に達したら、開発の契約を行います。 - 開発
- 業務分担に応じて双方が開発作業をします。外部設計書に基づきプログラミングやデータベースの実装などはベンダ側の業務ですが、得意先コードの設定や得意先台帳などの作成など、発注側が行う業務も多くあります。
- 検収・稼働
- ベンダ側のシステム開発が完了し、ハードウェアの設置などができたら、発注者立ち合いでテストを行います。それで満足すべき状態になったら発注側に引き渡します。
通常は数か月の仮稼働期間を設けて、その間にいろいろな不都合を見つけ、それが完了した時点で検収を行い、システムの引き渡しをします。
本稼働になった後でも、トラブルが発生するのが通常です。それで、瑕疵担保責任やＳＬＡ（サービスレベル・アグリーメント：納入システムの機能、アフターサービスに関する合意文書）を取り交わします。