曖昧な目的でシステムを導入すると、まず失敗します。無駄な情報投資は、無駄遣いという点と、業務を混乱させるという点の、２つにおいて悪です。

まずは目的を明確にしましょう。システム投資というより、経営改革という観点で、５年後１０年後の姿を想定しましょう。

現状の業務を洗い出しましょう。何を行っているのか。なぜ行っているのか。そして、改善することはできないか、検討しましょう。排除できないか、結合できないか、変更できないか、簡素にできないか。

見直した業務について、システム化対象を検討しましょう。コンピュータシステムを、仮想化した社員と考えてください。その仮想社員に何をやらせるのかを考えましょう。コンピュータが得意なのは、定型業務であり、大量の情報を迅速に正確に扱うことであり、24時間365日働くことであり、世界中を結ぶことができるということです。逆に、対人関係や、独創性や非定型業務は不得意分野なので、これは現実の社員にやらせましょう。

システム化対象が決まったら、どのような業務なのか、どの程度の品質要求なのかを決めましょう。これが要求定義です。要求定義が決まったら、情報システム提供者（ベンダー）に提案依頼書（ＲＦＰ）を作成して出しましょう。それを元に競争して提案してもらい、発注先を決めるのです。

設計を行うのは、情報システム提供者（ベンダー）の役割です。しかし、コンピュータシステムをブラックボックスとして、何をやらせるのか、どの程度の品質でやらせるのかを定義したものをチェックするのは利用者側の役割です。要求定義に即したものになっているかどうか、確認が必要です。これには一定の、情報システムの設計書に関する知識が必要になってきます。どのような表現方法の設計書にするかは、当初から決めておきましょう。

この部分の設計を、外部設計と言います（ベンダーによっては、概要設計と言ったり、基本設計や論理設計と言ったりしますが）。

この工程は、原則として情報システム提供者（ベンダー）の役割です。その工程はベンダーによって様々ですが、実装→単体試験→結合試験→総合試験→運用試験、といった流れになります。結合試験までは利用者側が検証するようなところではありませんが、総合試験は外部設計通りに実装されているかどうかを検証するものなので、可能な限りチェックしましょう。運用試験は要求定義に沿ったものかどうかを検証する物なので、結果を是とするか否とするかは利用者側の責任です。検証が不十分で、駄目なシステムを導入されても、文句は言えないでしょう。

工程定義はベンダーにきちんと確認しましょう。どこで何を目的として行うのか、誰が責任を持つのか。もっと細かい点だと、誰が環境を用意するのかなども契約に関連する事項として事前の取り決めが必要です。

情報システムは作って終わり、ではありません。作った段階が出発点です。利用者はいきなり使えるわけではありません。使い方を、業務に即して教育する必要があります。また、日々、業務に活用し、不具合に対応し、想定外の事項が発生したら対処方法を決め、有効活用するようにしなければなりません。必要なら社内ヘルプデスクを用意することもあります。これが運用です。

外部環境は変わります。社内の状況も変わります。コンピュータシステムだけがいつまでも変わらないで良いものではありません。陳腐化を防ぎ、必要な改修を行っていく必要があります。これが保守です。

情報システム提供者（ベンダー）側での経験を生かし、有用な情報システム構築を支援します。高い費用を出せばよいものではありません。費用対効果を考えた、自社の将来設計に合致したシステムを作らなければ意味がありません。ベンダーに振り回されないように、しっかりとして有用なシステムを作るためのお手伝いをします。

利用者側にも、情報システム提供者（ベンダー）側にも、情報システム構築のより良い手順についての研修を提供できます。自己流は事故の元。きちんとした手順を踏むことで、失敗する確率を下げることができるのです。

現在稼働している情報システムに関しての点検をしませんか。情報システムのセカンドオピニオンです。本当に効率的かどうか、将来的にどうしたらよいのか、調査分析し提案します。