情報システムの開発を外注するときの手順は、一般に次のようになります。
- 業務要件の検討
- 経営戦略やＩＴ戦略、利用部門のニーズなどから、開発するべき情報システムへの業務要件を検討します。
このとき、ＩＴの動向や類似業務のシステム化について、専門家（ベンダーやコンサルタント）からの情報を得たいことがあります。そのような情報提供依頼をＲＦＩ（Request For Information）といいます。これは発注を前提としたものではないので、ベンダの一方的なサービスになりますが、受注に参加したいベンダは積極的な情報提供をしてくれます。 - ＲＦＰの作成
- ＲＦＰ（Request For Proposal：提案依頼書）とは、複数ベンダに発注を前提した提案を求める文書です。
業務要件を整理して、何をしたいのかをベンダが理解しやすいように、より具体的に詰める必要があります。組織図や業務の流れ、想定されるデータの量、現在のシステムなど、システム構築に必要とされる多様な資料を添付します。
また、評価がしやすいように、ＲＦＰで提案書の記述内容を指定しておくことが望まれます。 - 提案書の分析
- ベンダからの提案書を比較検討して数社の候補に絞り、ヒアリングなどをして一社に仮決定します。このとき、提案を受けてから優劣評価の基準を決めるのでは、評価者の思惑が入りますので、客観的な評価ができません。ＲＦＰ作成時点で、評価基準－評価項目の設定、項目の重みづけ、項目の評価方法など－を作成しておき、それをベースにして部分的な調整を行い、評価するのが適切です（留意）。
事前の評価基準について経営者など決裁者の承認を得ておくことが重要です。
数社ベンダを候補にして提案書を検討しますが、経営者は見積金額だけに関心を持ちます。ＩＴ部門は、提案のそれぞれに評価やコメントをつけたりしますが、見積金額の順位を覆すだけの説得力がありません。費用が重要な評価要素なのは当然ですが、これが大きな危険をはらんでいることに留意する必要があります。
ハードウェアの費用やソフトウェアの保守費などが入っていないというのは極端ですが、文書化など付帯的な業務が欠けており、それが契約に含まれているかどうかが後でトラブルの原因になることがよくあります。また、データ入力での誤りデータのチェック機能などはピンからキリまでのレベルがありますが、ベンダが過少に低くとらえていることがあります。特にＷｅｂシステムでは、通常時とピーク時のアクセス数が極端に異なりますが、ピーク時の対処に考慮していないと、実施後大きなトラブルになります。このように、ベンダも気づかない手抜きはよくあるのです。 - システム仕様書、契約
- ＲＦＰは業務からの要件を示したものであり、提案書には情報システム開発の観点から修正したシステム要件が示されているはずですが、実際に情報システムを開発するには、もっと具体的に詳細にわたって検討する必要があります。そして、発注者とベンダの双方で協議した結果をまとめたのが外部設計書であり、それが契約条件として合意したものがシステム仕様書になります。
さらに協議を重ねて、発注者とベンダの業務分担、納期や費用などの合意に達したら、契約を行います（先に「仮決定」としたのは、このプロセスで合意に達しないときは、二番手の候補に変更することがあるからです）。 - 開発
- 業務分担に応じて双方が開発作業をします。外部設計書に基づきプログラミングやデータベースの実装などはベンダ側の業務ですが、得意先コードの設定や得意先台帳などの作成など、発注側が行う業務も多くあります（参照：システム開発での利用部門の任務 ）。
- 検収・稼働
- ベンダ側のシステム開発が完了し、ハードウェアの設置などができたら、発注者立ち合いでテストを行います。それで満足すべき状態になったら発注側に引き渡します。
本稼働になった後でも、トラブルが発生するのが通常です。それで、瑕疵担保責任やＳＬＡ（サービスレベル・アグリーメント：納入システムの機能、アフターサービスに関する合意文書）を取り交わします。